Xref: utzoo comp.windows.x:34714 comp.windows.x.motif:2377
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!stanford.edu!neon.Stanford.EDU!gerolima
From: gerolima@Neon.Stanford.EDU (Mark Gerolimatos)
Newsgroups: comp.windows.x,comp.windows.x.motif
Subject: Secondary Loop (within XtMainLoop) Problems
Message-ID: <1991Apr2.080151.10992@neon.Stanford.EDU>
Date: 2 Apr 91 08:01:51 GMT
Sender: gerolima@neon.Stanford.EDU (Mark Gerolimatos)
Organization: Computer Science Department, Stanford University, Ca , USA
Lines: 59

Given the following piece-o-traditional code:

	t ()
	{
		char file[25];
		do_something();
		scanf("%s",file);
		do_something_else(file);
	}

in which t() blocks in the scanf until *file* has been read...
I would like to implement this in an Intrinsic-based X program (as opposed to
X/View, which I am sure implements this, already, being that it's a spin-off
of SunView, which can do this), replacing the scanf with some sort of Modal
Dialog Box.
Now, the religiously correct way would be to break this down in the following
way:
t1 ()						| t2 (name)
{						| char *name;
	Callback OK_callback = t2;		| {
	do_something();				|   do_something_else(name);
	Bring_up_modal_dialog(OK_callback);	| }
	/* return to main loop */
} /* this code included to pre-empt religious flames */

But I would rather just implement this by having some call that brings up the
dialog box, blocks until somthing like "OK" has been clicked in the box, and 
then returns as if it were some sort of blocking read:
	t ()
	{
		char *name;
		do_something();
		name = Get_Name_From_Dialog_Popup();
		do_something_else(name);
		/* return to main loop */
	}

Clearly, Get_name_from... is going to have to implement a sub-event loop.
However, I've noticed that MOTIF 1.1 can behave in bizarre ways when this is 
done (often dying in some weird function called "_XmPopWidgetExtData()").
SIMPLE programs seem to work okay. However, in my code, I create, destroy, 
move, and manage many widgets (and even some modal dialogs which are themselves 
children of the original popup!), and the chance and severity of the failure 
seems to go up with the number of widgets I mess around with. This lead me
to believe that it is due to bugs in my code. 
However, I am beginning to believe that sub-event loops may in fact produce
undefined results (perhaps to due to recursively calling XtDispatchEvent?).
I can't find anything telling me that I CAN'T implement sub-loops, but I haven't
found any references telling me that I CAN, either. Can I?

What I need is an AUTHORITATIVE answer, not a religious one (i.e. "you SHOULDN'T
do this because it breaks the event-driven metaphor" is NOT an answer) as to
whether sub-event-loops are IMPLEMENTATIONALLY legal. 

References to documents are more than welcome. Thank-you.

-Krudbahr
	gerolima@wdl34.wdl.loral.com
		@neon.stanford.edu