d87-khd@sm.luth.se (Karl-Gunnar Hultland) (05/04/90)
I have some sort of problem with an application I'm working on.
I want to have a main program which should take care of menues etc and
then upon command Load and Create some new processes who will open a
window on the Custom screen and execute in that window.
The problem is :
If I comment away the LoadSeg and CreateProc and start the program
Proc.c via a different CLI it works Like a Dream. BUT if I use the
code in Main.c I never get the window to open.
I have verifyed with Xoper that the process exists but doesn't open
the window and thus it can't exit.
The question is: Is there ANYTHING I should do that I don't??
(code extracts follow .sig)
Karl
---
Karl Hultland,(d87-khd@sm.luth.se)
University of Lulea,Sweden
Egoist: a person of low taste, more interested in himself than in me.
- A. Bierce
=========================================================================
Main.c
=========================================================================
handleMSG(n)
int n;
{
if (segm1) UnLoadSeg(segm1);
MenuOn(0);
MenuOn(3);
return 0;
}
Load(n,msg,str)
int n;
struct OLFMessage *msg;
STRPTR str;
{
MenuOff(0);
MenuOff(3);
segm1=LoadSeg(str);
proc1=CreateProc(str,0,segm1,4000);
mesg1->Msg.mn_Node.ln_Type = NT_MESSAGE;
mesg1->Msg.mn_Length=sizeof(struct OLFMessage);
mesg1->Msg.mn_ReplyPort=OLFr;
mesg1->Code=HELLO;
mesg1->From=MAIN;
mesg1->To=TEST;
mesg1->scr=myscr;
SafePutToPort( (struct Message *) mesg1,"OLF");
return 0;
}
=========================================================================
Proc.c
=========================================================================
do {
msg=WaitForMsg("OLF",HELLO,TEST); /* Wait for WELCOME message */
} while (msg==NULL);
scr=msg->scr; /* Get address of screen */
TestWin.Screen=scr;
win=OpenWindow(&TestWin); /* Open window on customscreen */
signalmask=1L << win->UserPort->mp_SigBit;
while (!done){ /* Wait until closegadget is selected */
signals=Wait(signalmask);
if (signals & signalmask)
done=handleIDCMP(win);
};
if (win) CloseWindow(win);
if (GfxBase) CloseLibrary( (struct Library *) GfxBase);
if (IntuitionBase) CloseLibrary((struct Library *) IntuitionBase);
ReplyMsg( (struct Message *)msg );
}jmeissen@oregon.oacis.org (John Meissen) (05/04/90)
In article <897@tau.sm.luth.se> Karl-Gunnar Hultland <d87-khd@sm.luth.se> writes: >The problem is : >If I comment away the LoadSeg and CreateProc and start the program >Proc.c via a different CLI it works Like a Dream. BUT if I use the >code in Main.c I never get the window to open. >I have verifyed with Xoper that the process exists but doesn't open >the window and thus it can't exit. The problem may actually be related to the difference in the way that Workbench and CLI start processes. With the CLI, the new code is called as a subroutine (sort-of), and so the code is expected to fall right into executing. With WorkBench, the process is spawned as a seperate task, and is expected to wait for a message from Workbench with the arguments. These two diverse startup procedures are normally handled transparently in the C startup routine. In the case of Lattice (and this was the way recommended by Amiga way back when) the choice is made on the basis of whether or not the CLI sub-structure is present in the process structure. i.e., if the CLI structure pointer is non-NULL, get the argument pointer from the appropriate address register and continue executing. If it is NULL, wait on the msgport in the process structure for the Workbench message (which has to be returned at the end of execution). Now the problem you face is that CreateProc doesn't create a CLI sub-structure, so your code will think it's being spawned by Workbench and will wait for the Workbench message. It's probably either hung there, or that piece of the startup code ate your "hello" message and now it's waiting in the program for another message that will never come. -- John Meissen ............................... Oregon Advanced Computing Institute jmeissen@oacis.org (Internet) | "That's the remarkable thing about life; ..!sequent!oacis!jmeissen (UUCP) | things are never so bad that they can't jmeissen (BIX) | get worse." - Calvin & Hobbes
thyssen@focl5.cs.uq.oz.au (Anthony Thyssen) (05/07/90)
| signalmask=1L << win->UserPort->mp_SigBit; | | while (!done){ /* Wait until closegadget is selected */ | signals=Wait(signalmask); | if (signals & signalmask); | done=handleIDCMP(win); | }; Arrrrggghhhh..... Would ALL programers out there please include the BREAK_C signal flags in their code for testing for the close gadget It not only allow the user the send a break for easier testing but is a good thing to do.. To many programs Especially those for CLI don't do this Programers who leave it out should be shot.
new@udel.EDU (Darren New) (05/08/90)
In article <3504@moondance.cs.uq.oz.au> thyssen@focl5.cs.uq.oz.au (Anthony Thyssen) writes: > Arrrrggghhhh..... Would ALL programers out there please include >the BREAK_C signal flags in their code for testing for the close gadget >It not only allow the user the send a break for easier testing but is a good >thing to do.. To many programs Especially those for CLI don't do this >Programers who leave it out should be shot. AND ALSO Leave The BREAK_D Signal Alone! Even Lattice mucks this up. BREAK_D is for stopping a shell script without disturbing the currently running program, so only shells should be testing this bit! This was documented back in the 1.1 RKMs. -- Darren