gerolima@Neon.Stanford.EDU (Mark Gerolimatos) (04/02/91)
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.edupaulb@siesoft.co.uk (Paul Bentley) (04/03/91)
I have also experienced considerable difficulty in making subsiduary event loops work in Motif 1.1 and have spent several days producing short (50 lines approx.) example programs. The manifestation of these problems are in my experience always obscure, so obscure infact that you have to spend a lot of time convincing yourself that you have not made the mistake in your own code. My opinion is that any problem caused by the use of subsiduary event loops is a bug. I have never seen anything in writing to say that they are not allowed, and the bugs that appear are just too obscure to be features. However I do accept the point of view that subsiduary event loops should be avoided. My advice would be not to write any new applications using subsiduary event loops. I'm in the unfortunate position of maintaining old code ported to Motif (far from ideal) which has blocking subsiduary event loops called from 70 places ! -------------------------------------------------------------------------------- Paul Bentley (paulb@siesoft.co.uk) Siemens Nixdorf Informations Systems Limited Siemens Nixdorf House Oldbury, Bracknell Berkshire RG12 4FZ England.
gjc@mitech.com (04/04/91)
In article <1991Apr3.092416.8894@siesoft.co.uk>, paulb@siesoft.co.uk (Paul Bentley) writes: > ... I'm in the unfortunate position of maintaining old code ported > to Motif (far from ideal) which has blocking subsiduary event loops called > from 70 places ! > In this kind of situation, if you want to be 100% sure of avoiding subsiduary event loop bugs, probably your best and only way of handling this is to have all MOTIF/X activity handled by a front-end process, and run your actual application as a subprocess, talking to it via pipes. One example I have: Using a modified version of the XTEK (tek 4010 emulator) code that I mentioned here and posted to VMSNET.SOURCES a while back, myself and other people have added some pulldown menu capability and a simple dialog box for text input, to * Turn an arbitrary old (say) FORTRAN program which prompted the user for interactive commands and output graphics in Tektronics codes into "=>" a spiffy new looking X-Window program with pulldown menu's and mouse-sensitive graphical items. The main issue is keeping track of the state of the conventional interactive subprocess. That is: WHEN it is ready to accept input, and when it is not. In some operating systems you can determine this without any modification of the program. In most you cannot, although simple conventions will work most of the time, and finally, replacing all READ requests with a subroutine that will send an escape code to the superiour process at the start and end of each READ will do the trick. (1) start with a toplevel shell widget that has a (a) pulldown menu bar. (b) simple window for drawing tex graphics commands. (c) a text widget for shunting otherwise non-handled text output. (d) a command line widget (e) a dialog box for handling the most common single-line-question, single-line-response commands. (f) other dialog boxes for handling choice-like menus. and other things you think up as the interface evolves. (2) Shunting TEK graphics commands to the graphics window is trivial. (3) Shunting non-graphics commands to the non-graphics text area is also trivial, since most old programs have a convention for going from graphics-output to "interactive mode". Many were already modified (or developed) to work with TEK-Emulation of VT100 or VT240. And there are specific escape codes involved here. (4) Adding pulldown menu items to send specific commands is trivial. (5) Even mouse-sensitive items is easy. A mouse click can be encoded in a conventional way and sent as a command: (a) CMD>MOUSE_CLICK_AT x,y or some simple recognition of object name (you have to keep a display list of all lines, circles, and strings written to your X window anyway) can turn things into (b) CMD>SELECT_DETAIL_ON OBJECTXYX -gjc p.s. XTEK is available for anonymous FTP. An archive site for VMSNET.SOURCES is CERRITOS.EDU. The GJC archive site is BU.EDU, cd to users/gjc
pel@ctron.com (Paul Leclerc) (04/05/91)
In article <1991Apr3.092416.8894@siesoft.co.uk> paulb@siesoft.co.uk (Paul Bentley) writes: > I have also experienced considerable difficulty in making subsiduary > event loops work in Motif 1.1 and have spent several days producing short > (50 lines approx.) example programs. The manifestation of these problems > are in my experience always obscure, so obscure infact that you have to > spend a lot of time convincing yourself that you have not made the mistake > in your own code. > > My opinion is that any problem caused by the use of subsiduary event loops > is a bug. I have never seen anything in writing to say that they are not > allowed, and the bugs that appear are just too obscure to be features. In fact, in the Motif book by Douglas Young, he suggests that the only way to have blocking dialog boxes is to use another event loop ( page 116). Of course no other mention is made nor any explanation made as to how you go about doing this (for us X/Motif novices) > However I do accept the point of view that subsiduary event loops should be > avoided. So then how do we write dialog boxes or other things that block until certain events occur? > My advice would be not to write any new applications using subsiduary > event loops. I'm in the unfortunate position of maintaining old code ported > to Motif (far from ideal) which has blocking subsiduary event loops called > from 70 places ! Paul L. -- pel@ctron.com #include <disclaimer> Cabletron Systems Inc.
bschoen@well.sf.ca.us (Brook Schoenfield) (04/13/91)
In article <PEL.91Apr4133758@pan.ctron.com> pel@ctron.com (Paul Leclerc) writes: >In article <1991Apr3.092416.8894@siesoft.co.uk> paulb@siesoft.co.uk (Paul Bentley) writes: > >> I have also experienced considerable difficulty in making subsiduary >> event loops work in Motif 1.1 and have spent several days producing short >> (50 lines approx.) example programs. >> >> My opinion is that any problem caused by the use of subsiduary event loops >> is a bug. I have never seen anything in writing to say that they are not >> allowed > >In fact, in the Motif book by Douglas Young, he suggests that the only >way to have blocking dialog boxes is to use another event loop ( page 116). The documentation for the Xt Intrinsics says something like: "there is nothing special about XtMainLoop, it consists of the following two calls: XtNextEvent() XtDispatch() (please forgive me if I have the exact spellings of these off......I have to do my news reading at home) After thinking about this problem for three months and reading these words about 20 times, it finally sunk in that there is nothing special about XtMainLoop(). While callback architecture is encouraged, it is not holy. I do this whenever I need to block for awhile, and I've nested calls. The problems that I've had have all been traced to my own code: if I have forgotton that I've got timer or idle events, weird things do happen. I get rid of anything in the background that I don't need and am careful to watch what events are coming down the pike that I will need to deal with (either by passing through to my own callback routines or by dealing with at the moment: for instance waiting on a keystroke or a button press). By the way, all the Xperts told me this could not be done: redesign. I couldn't afford the time on the project. -- Brook Schoenfield bschoen@well.sf.ca.us