Conference hydra::amiga_v1

	It's hard to tell without the whole program and it's been a while.
	Fish Disk 344 is the RKM companion for the 1.3 ROM kernel.
	It expands to 2 disks and has short
	examples that actually work compiled
	ready to go , with sources.
	I had the same problem you are having with book examples.
Tom (on fish 356)

    Thanks for the pointer. I've just grabbed FF344 and am extracting it
    now.
    
    Tom
    

    I printed out the 2 examples from ff344 and compared them to the RKM
    and there's no difference that I can see. I'll have to wait till I get
    home to try and compile them. They were compiled with lattice 5.02. I'm
    running 5.05. Maybe I screwed something up when I upgraded from 5.04a
    to 5.05 with the file I pulled off the lattice bulletin board. I really
    haven't done much compiling since then. I do run ARP and I remember
    somebody reporting problems upgrading with the arp exec command. Could
    this be my problem? Maybe I'll have to reinstall from my original 5.04a
    floppies. I've been thinking about upgrading to the new SAS compiler
    but I'd like my old one to at least compile the examples.
    
    Tom

It's always good to compile some "know compilable" program to see if
your compiler is totally wacked out.

john

    Well, it wasn't the RKM examples and it wasn't my compiler, it was just
    me - programmer error. After I opened my window I only had a single =
    when checking the returned pointer for NULL. I must have gone through
    it 10 times and not caught it. I'm glad I wrote this note though, the
    RKMCompanion disks were a big help. I found it with a diff between the
    files. And getting the examples on disk sure beats typing them in.
    
    Thanks for the help,
    
    Tom
    
    ps - now if I could just figure out how to get input from my new window
         I'd be happy. I might as well ask.
    
         Is there any way to get my new window to be stdin and stdout so
         I can do simple printf and scanf to it ?
    

     One way to get "console" input is through the use of the console.device.
This may be associated with a window(s), and then IO is done through
the standard DoIO, SendIO, etc.  Examples of this can be found in
Peck's "Programmer's Guide to the Amiga", and probably the in RKMs.

     Probably what you really want is a more transparent variety, so that
you can printf, scanf, etc.  One way you can do this is using fopen, etc,
in conjunction with CON: or NEWCON:

#include <stdio.h>
main()
{
    FILE *wp;
    if ((wp = fopen("NEWCON:0/0/400/200/Test Window", "r+") != NULL) {
	fprintf(stdout, "testing...");
	Delay(150);
	fclose(wp);
    }
}

     This may not help either since all you have is a FILE, and you don't
have access to the IDCMP events, etc.  There are ways to really hack things
and get at the window, but it's probably not recommended.

     Maybe your best bet is looking at the "console.device".  IO operations on 
the Amiga are really pretty easy to use (I'd almost call it fun :^), and they 
are quite flexible.

Steve - I feel like I'm forgetting something easier...
	(There _should_ be some NewWindow flags to enable this type of
	behavior - both console and intuition activity)

That short example isn't going to do much good with:

fprintf(stdout, "testing...");

use:	

fprintf(wp, "testing...");

Re: .5

>    ps - now if I could just figure out how to get input from my new window
>         I'd be happy. I might as well ask.

There are IDCMP events for this, just like they are for WINDOWCLOSE,
WINDOWREFRESH, and WINDOWSIZE.  You get a message with the data in
it.

>         Is there any way to get my new window to be stdin and stdout so
>         I can do simple printf and scanf to it ?

A little background:

On the Amiga, a programmer can access windows on three different levels.

The lowest level is Intuition.  On this level, you do things to the window
by calling Intuition or graphics routines passing a pointer to the
window or the windows rastport (window_ptr->RPort).  The window sends
information back via messages to the IDCMP (Intuition Direct CoMmnication
Port).  You create an Intuition window using OpenWindow().

The next higher level is the console.device.  The console.device is
an Exec level device that allows a programmer to manipulate a window
using Exec level I/O.   Exec level I/O is a message passing based I/O
(like IDCMP messages), but you can do output as well as input using
messages.  Instead of calling a graphics routine to put text in the
window, you can send a buffer of text via message to the window.
One of the biggest advantages of the console.device is that it
will handle ANSI escape sequences in text output.  You create
a console.device window by opening an Intuition window using
OpenWindow(), and then calling the Exec OpenDevice function
passing in the window pointer as an argument.  The programmer
can manipulate the window using either Intuition or the console.device.

The highest level is AmigaDOS CON: windows.  AmigaDOS proper, is the
part of the Amiga operating system than handles file I/O.  Simply
by opening the CON: device, AmigaDOS will open an intuition window,
open a console.device based on that window, and start a file system
task to accept normal read and write calls to do I/O to the window
as if it was a file.

For example, the following untested function should open a window named
"My Window", print "Hello World" followed by "Press Return".  When you
press return, the main() function will return, the C I/O system will
close the "file", and the window will vanish.

#include <stdio.h>

main()
{

    FILE *f;

    f = fopen("CON:0/0/640/100/My Window", "r+");
    if (f == NULL) {
	perror("My Window");
	exit(1);
    }

    fprintf(f, "Hello, world!\nPress Return\n");
    fgetc(f);
}

By sending an obscure message to the file system task handling
the CON: window, it is possible to obtain the console.device
pointer and the Intuition window pointer.  Thus, CON: windows
can be manipulated though the file system, though the console.device,
or though Intuition.  The only drawback to CON: windows is that
there are certain window properties that can only be set when
a window is opened (for example, whether the window has a close window
system gadget).  Since AmigaDOS opens a CON: window using its
favorite defaults, you can't get every flavor of window you might
like this way.

Re: .6

Sigh!  I knew I was taking too long typing .8.

It is supported to manipulate a CON: window as a console.device window
or an Intuition window.  The problem is that the documentation is
very obscure.  It's in a back section of the AmigaDOS manual by Bantam.
The discussion is AmigaDOS packets that can be sent to file system
tasks.  The Volume (or disk?) Info packet when sent to a CON:-like
handler returns console.device and Intuition pointers.

Note that intermixing con: (or console.device) output into a window
and graphics isn't really supported. If you do it carefully (i.e. - 
be in either one mode or the other, or draw in 1/2, and define the other
half as a scrolling region, if possible), you should be ok.

The problem is that, as of 2.0, the console handler has some intelligence
in it for updates. It won't scroll your graphics for you. Under 1.3, this
wasn't the case.

	<mike

    I got so busy this last week that I haven't even had time to get
    into notes to thank everyone for the help. I didn't want anyone to
    think that I wasn't reading their replies. They were a big help.
    
    Thanks,
    
    Tom

    Does anybody know if the mutual-exclude field of a gadget is used by
    Intuition?
    
    I ask this because I own an old version of RKM (1.1) and this field is
    flagged as ignored by that old version of Intuition.
    
    Now I'm not able to get this field working with 1.3 either, and I'm
    thinking Intuition still doesn't look at this field.
    
    So anybody knows what is going on?
    
    Thanks 
    Roberto

	I have a recent version of the RKM. It says that mutual exclude is
still not implemented. I found out the hard way. There are at least two examples
of code to implement mutual exclusion on fish disks somewhere. I wrote my own
version. It's not fully general, but it gave me what I needed. I could upload
it if you want.

    Please upload,
    
    right now I have to refresh every single gadget I whish to deselect 
    with RefreshGadget from mxm.library, but with ~20 gadgets
    it's a pain!!.
                                                   
	Thanks

    	I have uploaded my routine to handle the mutual exclude field for
    gadgets to 
    
    tape::amiga:[upload]m_exclude.lzh 
    
    For two more examples of code to handle this, check out FF31 and FF52.
    Good luck...
    
    								- Bob