dickie@schaefer.math.wisc.edu (Garth Dickie) (04/06/91)
Followups have been redirected to comp.sys.mac.programmer In article <1991Apr5.231457.4032@dartvax.dartmouth.edu> ari@eleazar.dartmouth.edu (Ari Halberstadt) writes: >What's the easiest way to convert an application to modeless dialogs? >Use only one event loop! Don't call WaitNextEvent from 10 places in >your code, call it only from the top of the event loop, and make your >event loop reentrant so that it can be run from the middle of a long >calculation. I'm not sure how this fits into MacApp, but I imagine >MacApp does a similar thing. Converting alerts into dialogs also >simplifies life (I'm prepared to defend this position, so only flame >me about this if you want to have fun :). Not a flame: I think making the event loop reentrant causes more problems than it solves, in user interface terms. I get the effect you seem to desire simply by always returning to the main event loop, with enough state (not very much) saved in my application_c instance to know what I'm doing. I implement all dialogs, modal or not, as ordinary windows, and simply modify my event loop behaviour to reflect the fact that there is a modal window present. This makes it very simple, among other things, to implement the (emerging standard?) live menubar during modal dialogs, with whatever items are appropriate (editing, ususally) available. On a slightly more nonstandard note, I also return to the main event loop during mouse tracking. The preserved state in this case is a routine to call with the mouse location and modifiers. This makes the handling of screen updates completely orthoganal across the application, makes sure to allow time to background processes, and makes it simpler to allow time to background psuedo-threads within the application -- ongoing calculations which are given time periodically on null events, etc. I think there is a principle in what you propose for SF: special cases are bad, orthoganality makes things simpler. I have certainly found that after a little pain converting to the above, writing correct code is much easier. And ask anybody who has coded 80x86 and 680x0 which is simpler to code for :-) -- Garth Dickie -- Confused Math Graduate Student -- dickie@math.wisc.edu