lkoop@pnet01.cts.com (Lamonte Koop) (01/11/91)
I'm having a problem utilizing a shared IDCMP port setup on a window
arrangement, and wonder if anyone can see a problem with what I'm doing.
I have one main window, and a second window is opened, after which I make
the following assignment;
secondwin->UserPort = firstwindow->UserPort;
Ok...all's well, all of my messages are coming into the first window's
UserPort. I don't need to check the IDCMPWindow portion of my IntuiMessages,
due to the arrangement I have set up, but rather just ReplyMsg() to each
message I process as if it were from one window. Now, the problem comes when
I try to close the second window. NOw, I realize you cannot simply do this
normally, so I use the following routine:
void SafeClose(swin)
struct Window *swin;
{
struct IntuiMessage *msg;
struct IntuiMessage *succ;
struct MsgPort *mp = (struct MsgPort *)swin->UserPort;
Forbid();
msg = (struct IntuiMessage *)mp->mp_MsgList.lh_Head;
while(succ=(struct IntuiMessage *)msg->ExecMessage.mn_Node.ln_Succ) {
if (msg->IDCMPWindow == swin) {
Remove(msg);
ReplyMsg(msg);
}
msg = succ;
}
swin->UserPort = NULL;
Permit();
CloseWindow(swin);
}
Generally, calling this results in a corrupt memory list guru. Now, anyone
have a suggestion? I realize this is an old topic, but I cannot find
referernces to it presently.
LaMonte Koop
Internet: lkoop@pnet01.cts.com ARPA: crash!pnet01!lkoop@nosc.mil
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop
A scientist is one who finds interest in the kinetic energy of Jell-O
moving at ridiculous velocities...an engineer is one who can find a
real-life application for such silliness.bj@cbmvax.commodore.com (Brian Jackson) (01/11/91)
In article <6841@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: > >I'm having a problem utilizing a shared IDCMP port setup on a window >arrangement, and wonder if anyone can see a problem with what I'm doing. > [...] >Now, the problem comes when I try to close the second window. NOw, >I realize you cannot simply do this normally, so I use the following >routine: > >void SafeClose(swin) >struct Window *swin; >{ > struct IntuiMessage *msg; > struct IntuiMessage *succ; > struct MsgPort *mp = (struct MsgPort *)swin->UserPort; > > Forbid(); > msg = (struct IntuiMessage *)mp->mp_MsgList.lh_Head; > while(succ=(struct IntuiMessage *)msg->ExecMessage.mn_Node.ln_Succ) { > if (msg->IDCMPWindow == swin) { > Remove(msg); > ReplyMsg(msg); > } > msg = succ; > } > swin->UserPort = NULL; > Permit(); > CloseWindow(swin); >} > >Generally, calling this results in a corrupt memory list guru. Now, anyone >have a suggestion? I realize this is an old topic, but I cannot find >referernces to it presently. > Try adding ModifyIDCMP(swin,0L); between the Permit() and the CloseWindow() calls. It's the only difference between yours and the one that I have (that works.) bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "My beer comes from farther away than your beer." | -----------------------------------------------------------------------
bj@cbmvax.commodore.com (Brian Jackson) (01/12/91)
** Error Correction ** In article <17379@cbmvax.commodore.com> bj@cbmvax.commodore.com (Brian Jackson) writes: >In article <6841@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: >> >>I'm having a problem utilizing a shared IDCMP port setup on a window >>arrangement, and wonder if anyone can see a problem with what I'm doing. >> [...] >>Now, the problem comes when I try to close the second window. NOw, >>I realize you cannot simply do this normally, so I use the following >>routine: >> [ some example code deleted ] >> swin->UserPort = NULL; >> Permit(); >> CloseWindow(swin); >>} > >Try adding > > ModifyIDCMP(swin,0L); > >between the Permit() and the CloseWindow() calls. It's the only >difference between yours and the one that I have (that works.) > >bj Argh!! Try adding it BEFORE the Permit() call! My mistake (the excuse is my staying up all night playing with computers). Thanks to Peter!! ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "It can be done." != "It should be done." | -----------------------------------------------------------------------
wsc1@cunixb.cc.columbia.edu (William S Chou) (01/12/91)
In article <6841@crash.cts.com> lkoop@pnet01.cts.com (Lamonte Koop) writes: > >I'm having a problem utilizing a shared IDCMP port setup on a window >arrangement, and wonder if anyone can see a problem with what I'm doing. >I have one main window, and a second window is opened, after which I make >the following assignment; > >secondwin->UserPort = firstwindow->UserPort; This is besides the point in question but aren't you wasting memory here? Your UserPort is unlinked here and you haven't bothered to restore it when you close the window. (from the Code below) Assuming Intuition allocates UserPort rather than just give you a pointer to an existing port. >void SafeClose(swin) >struct Window *swin; >{ > struct IntuiMessage *msg; > struct IntuiMessage *succ; > struct MsgPort *mp = (struct MsgPort *)swin->UserPort; > > Forbid(); > msg = (struct IntuiMessage *)mp->mp_MsgList.lh_Head; > while(succ=(struct IntuiMessage *)msg->ExecMessage.mn_Node.ln_Succ) { > if (msg->IDCMPWindow == swin) { > Remove(msg); > ReplyMsg(msg); > } > msg = succ; > } > swin->UserPort = NULL; > Permit(); > CloseWindow(swin); >} > >Generally, calling this results in a corrupt memory list guru. Now, anyone >have a suggestion? I realize this is an old topic, but I cannot find >referernces to it presently. > > > LaMonte Koop > Internet: lkoop@pnet01.cts.com ARPA: crash!pnet01!lkoop@nosc.mil > UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!lkoop > A scientist is one who finds interest in the kinetic energy of Jell-O > moving at ridiculous velocities...an engineer is one who can find a > real-life application for such silliness. ___________________________________________________________________________ // "Be Excellent to Eachother" - Bill & Ted \\ // "And Most of All Be Excellent to Your Amiga" \X/ - Will wsc1@cunixb.columbia.edu ___________________________________________________________________________
gilmore@macc.wisc.edu (Neil Gilmore) (01/13/91)
In article <6841@crash.cts.com>, lkoop@pnet01.cts.com (Lamonte Koop) writes... > >I'm having a problem utilizing a shared IDCMP port setup on a window >arrangement, and wonder if anyone can see a problem with what I'm doing. >I have one main window, and a second window is opened, after which I make >the following assignment; At the risk of sticking my neck out... I also had a problem with shared IDCMP ports, even though I was (apparently) doing everything correctly. Your routine looked right (I used the one from the RKM's nearly verbatim also). My problem turned out to be that I was using the menu to select when to close a window, the window which generated the message. Unfortunatly, I was using the real message, not a copy, and replying at the end of an event loop. What would happen was the message woudl come in, I'd close the window, then Reply() to the message. Of course, by the time I'd Reply(), the window didn't exist, or maybe the message I was Replying to was alredy Replyed to. In any case, a quick trip to the guru. The problem wasn't in closing the window, but what went on around closing the window. Now, I copy the message and Reply() immediately, and haven't crashed since on closing a window. Hope this helps.
gregg@cbnewsc.att.com (gregg.g.wonderly) (01/18/91)
From article <1991Jan13.084228.25939@macc.wisc.edu>, by gilmore@macc.wisc.edu (Neil Gilmore): > I also had a problem with shared IDCMP ports, even though I was > (apparently) doing everything correctly. > My problem turned out > to be that I was using the menu to select when to close a window, the > window which generated the message. Unfortunatly, I was using the real > message, not a copy, and replying at the end of an event loop. > Now, I copy the > message and Reply() immediately, and haven't crashed since on closing a > window. I had a problem like this too... Now I realize why all of the RKM examples are written as class = imsg->Class; gadgptr = (struct Gadget *)imsg->IAddress; ...etc ReplyMsg( (struct Message *)imsg ); switch( class ) { case MENUPICK: ... break; case GADGETUP: ... break; ...etc } They really seem to be suggesting that you should reply to the packet before you proceed! -- ----- gregg.g.wonderly@att.com (AT&T bell laboratories)