🚀 go-pugleaf

In article <7412@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes:
>	Consider:  Not all programs open windows (the CLI commands are good
>examples of this).  Some programs which do open windows open only DOS
>windows, for which IDCMP access is at best difficult, and handled by DOS
>anyway (and knowing DOS, it will probably get seriously confused if foreign
>messages start arriving at ports it manages).  Also, some programs open more
>than one window; how do you know which IDCMP port to send it to?

	No one said you had to send the messages to a real IDCMP port.
You can use a private port if you wish (any port at all - just CreatePort()
it).

>	I feel that IPC communication should occur through a process's
>pr_MsgPort.  All processes are guaranteed to have one and only one, they're
>always in the same place, and they're guaranteed to exist as long as the
>process exists.

	I can see you've never written a dos handler.  :-)  If you had, you'd
know about AN_AYNCHPACKET, the error dos gives if it finds a packet it
doesn't like.

>	Another thought occurs to me:  Perhaps the reason you want to go
>through the IDCMP port is so that programs that don't support IPC but get
>sent IPC messages will simply ignore and return them.  I don't see how this
>could be made to work elegantly for the pr_MsgPort (DOS currently throws up
>a deadend alert if it's waiting for one kind of packet and something foriegn
>arrives).  However, you may wish to consider that some programmers, like
>me, have the following statement in their event switch () loop:

	No, this has nothing to do with it.  You have to request a
server to send you packets, they won't do it spontaneously.

-- 
You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software.
Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup