Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!think!ames!ucbcad!ucbvax!hplabs!hpda!hpesoc1!hpindda!grant From: grant@hpindda.HP.COM (Grant Haidinyak) Newsgroups: comp.sys.amiga Subject: Re: Burning Questions Message-ID: <6570004@hpindda.HP.COM> Date: Mon, 30-Nov-87 22:26:47 EST Article-I.D.: hpindda.6570004 Posted: Mon Nov 30 22:26:47 1987 Date-Received: Sat, 5-Dec-87 01:22:29 EST References: <6570001@hpindda.HP.COM> Organization: Hewlett Packard, Cupertino Lines: 86 >Didn't you mean "Request(rqstr,win_main);" here? The variable log_rqstr >doesn't seem to be initialized by the above code. Also if you declare >log_rqstr as a struct Requester then the above call will work but if >you declare it as a struct Requester * then the & above causes the >C compiler to pass a pointer to a pointer to a struct Requester. Sorry about that. The Initial code is in a procedure that intializes the requester sturcture, and the end line was the actual line that is code, so the code looks something like: make_log_rqstr(rqstr) struct Requester *rqstr; { /* initialization code */ } get_log() { make_log_rqstr(&log_rqstr); Request(&log_rqstr, win_main); } Also, I had a WindowToFront(win_main) before the get_log() call, but when I took the call out, the requestor appeared when specified. (win_main was already to the front of the window stack). >Well, this should work if you set it up correctly. When you say 'double click' >are you referring to the select button or the Menu button of the mouse ? I >ask because if the requester flags are set with DMREQUEST then it takes >a double menu click to bring up the requester. What I mean by double click, is click on the left (select) button twice. >>Also, I'm writing a program that has multiple windows being opened, that >>are attached to one port. The problem that I have found with this is: >> >> 1) A Close request for a window comes in. >> 2) I Close the window, the messages associated with this window >> get deallocated. >> 3) There are still pending messages for the window queued to the port. >> 4) I start to process the queueed messages. >> 5) Guru because of bad next link pointer (memory had been deallocated). > >The magic is that you open your initial window, then subsequent windows >you open with NULL IDCMP Flags, and copy the message port pointer from >the initial window into the new windows structure. Then use ModifyICMP() >to set the events you want to see. Before closing the window you do the >same thing in reverse. ModifyIDCMP() back to nothing, set the message >port pointer to NULL, and then close the window. Let the parent window >dispose of any extra messages. I'm not opening an initial window, I'm just opening a standard port. Also, the setup described above, is correct. However, closing the window isn't how it is described in the "Intuition" manual (which could now be out of date, as I have the original manuals). In the manual, to close a window with a shared message port, it says to NULL out the message port field in the window structure, but to leave the IDCMP field alone. The is a "Grim, Forboding Note" however, the manual says that if you don't reply to the messages, there will probably be a GURU. (paraphrased) I tried resetting the IDCMP's to NULL, and then resetting the message port to NULL, but the also GURU'ed the machine. >> There are good points, and bad points associated with each method, but >> I'd like to know which is accepted, or if there is a standard way of >> doing this already. > >The above is the 'accepted' way of doing that. It's based on an example >that Jim Mackraz did which included a routine CloseWindowSafely() that >took care of the message port stuff. Would you or anyone else please post, or tell me where to get the CloseWindowSafely() routine. (I want to do things "right", not just do them) Also, since I'm on my soapbox, how do I get the Autodocs that are refered to by the Enhancer Manual. >--Chuck McManis Grant Haidinyak