mwm@violet.berkeley.edu (Mike (My watch has windows) Meyer) (09/21/87)
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. I know that I'm doing a *very* hazardous thing. Suggestions on a better way to do it will be appreciated - except I'd rather not put false mouse events into the intuition stream. Thanx, <mike -- Round about, round about, in a fair ring-a. Mike Meyer Thus we dance, thus we dance, and thus we sing-a. mwm@berkeley.edu Trip and go, to and fro, over this green-a. ucbvax!mwm All about, in and out, over this green-a. mwm@ucbjade.BITNET
cmcmanis@sun.uucp (Chuck McManis) (09/21/87)
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 uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses. But you knew that, didn't you.
jimm@mitsumi.UUCP (Jim Mackraz) (09/22/87)
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
ralph@mit-atrp.UUCP (Amiga-Man) (09/23/87)
In article <277@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes: >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 Yep. And while your at it, make the thing iconify itself when it goes quiescent. Thus you ask the application to "get outta the way, but don't die" and it turns into an icons *on the workbench screen*. Then to reactivate you either double click it, or double click some project which has that program as it's default tool. Then, if it's an editor, it loads that project into another buffer, keeping the original stuff intact too. I believe I've seen this performance in the X window system. It's really needed since one often needs more screen space but would like to either keep programs running, or actually make them quiescent, *but* without losing the present state. The only program I've seen which does something like this is UEDIT, but it doesn't make an icon, it just makes a small window. It must be possible to get an icon out there from in a program. I've managed to drag all sorts of things out there manually. Ralph. PS: Commodore-Amiga ! Fix Da Workbench ! Drawers open too slow ! Please ? (I'm slowly going crazy, but I won't go back to typing commands... computers ought to be *FUN* !).
spencer@eris.BERKELEY.EDU (Randy Spencer) (09/26/87)
In article <1569@mit-amt.MEDIA.MIT.EDU> ralph@ATRP.MEDIA.MIT.EDU (Amiga-Man) writes: >In article <277@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes: >>PS: I thought of a possible pair of standard commands: GoQuiescent and FireUp. >> Jim Mackraz > >Yep. And while your at it, make the thing iconify itself when it goes > Ralph. I would love to have the thing iconify itself, the problem is that anything that you put on the Workbench screen will keep the Workbench from closing. What would be more useful would be a program that, when run loads the real program, unless the real program is loaded, in which case it tells the real program to open its windows and start talking. Kind of like Commodities is now, but doesn't get the "I don't own an IBM any more, I own an Amiga! What do I need with Hot Keys?!?" complaint. 'Course, the above can be done now, so you don't need to modify the machine any to do it. Neat, huh? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
randy@bcsaic.UUCP (Randy Groves) (09/28/87)
Is Commodities a product?? I've seen several people mention it, but so far no info on how to get it, how it's sold, if it's not PD, etc. Thanks much. -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124
peter@sugar.UUCP (Peter da Silva) (09/29/87)
> I would love to have the thing iconify itself, the problem is that anything > that you put on the Workbench screen will keep the Workbench from closing. Amiga Intuition Reference Manual, appendix B: #define WBENCHMESSAGE 0x00020000 /* IDCMP class */ #define WBENCHOPEN 0x0001 /* IDCMP code */ #define WBENCHCLOSE 0x0002 /* IDCMP code */ What do you suppose would happen if you opened a window with WBENCHMESSAGE in its IDCMPFlags? -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.