Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!oliveb!amiga!mitsumi!jimm
From: jimm@mitsumi.UUCP (Jim Mackraz)
Newsgroups: comp.sys.amiga
Subject: Re: Feeding a windows IDCMP port
Message-ID: <277@mitsumi.UUCP>
Date: Tue, 22-Sep-87 13:28:11 EDT
Article-I.D.: mitsumi.277
Posted: Tue Sep 22 13:28:11 1987
Date-Received: Thu, 24-Sep-87 06:34:39 EDT
References: <5178@jade.BERKELEY.EDU> <28632@sun.uucp>
Reply-To: jimm@mitsumi.UUCP (James Mackraz)
Organization: Mitsumi Technology Inc
Lines: 74

In article <28632@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes:
>In article <5178@jade.BERKELEY.EDU> mwm@violet.berkeley.edu (Mike (My watch has windows) Meyer) writes:
>>
>>I would like to feed applications IDCMP events from outside the
>>applications. Most notably, I'd like a CLI command:
>>
>>	closewindow Name
>>
>>That finds the window named Name, and tells it that it's close gadget
>>has just been hit.
>>
>>The obvious hack (chase down the window, and feed an IntuiMessage to
>>it's UserPort) didn't work. The application apparently never saw the
>>message, the closewindow program hangs, and the system GURUs when the
>>application is close for real.
>>
>
>This is due to the very protective nature that Intuition has over its
>(not your) IDCMP message port. According to jimm the big "I" *knows*
>that all the messages going to that port are in memory that it owns
>and has to free, etc. When *you* send a message their you probably
>confuse the heck out of it. A more disgusting, but more effective 
>hack is to chase down the window, find out where on the screen the
>close gadget is, then send a MOUSEEVENT into the input stream that 
>is a click on the close gadget. Then Intuition can make up a Close Window
>message for you and send it to the IDCMP port. If you this is your own 
>program then you can give it your own 'public' port and send messages 
>to that. Of course this is what aREXX does for you. Anyone want to come
>up with a minimum common command set for a remote control language? 
>Maybe another well know port like RCMP (Remote Control Message Port).
>We define a common set of 'Messages' that can be sent to these ports
>and do the same approximate things (OPEN, CLOSE, READ, WRITE, UP, DOWN,
>etc) 
>-- 
>--Chuck McManis

As unattractive as it may seem, sending an input event is a safer
thing than trying to get involved with Intuition's use of the IDCMP port.
It's a little unclear exactly why it blows up if the reply port of
the message you send is valid (probably).  Intuition indeed frees the
unread message hanging off of the port, but all programs delink them
with GetMsg() before acting on them, don't they?

One thing seems certain: management of the IDCMP messages is an area that
needs improvement.  Nasty side effects of hacking in this area are
guaranteed.

Note that all of this discussion is ripe with validity problems: you
send a message to the IDCMP port, but what if the port is, poof, gone
before the message arrives?  When dealing with ports at large, you 
typically must: Forbid(); find_port(); PutMsg(); Permit();  

Owners of ports which may be accessed by the world at large must be
careful deleting them.  This works: RemPort( or equivalent ); read
and handle all messages; delete port.  This doesn't: read all messages,
remove, delete.

There is a validity problem even with feeding mouse events: no ironclad
guarantee that the close gadget is still where you found/calculated it
to be.

Isn't this fun?

	jimm

PS: I thought of a possible pair of standard commands: GoQuiescent and FireUp.
The former is a request that an application minimize its resources (close
windows and the like), and the latter is a request to reappear and swing
into action.  This gives simple "TSR" or pop-up "resident" programs without
everybody monitoring the input food chain.
-- 
	Jim Mackraz
	Mitsumi Technology, Inc.		408/980-5422
	{amiga,pyramid}!mitsumi!jimm