Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ncar!tank!tartarus.uchicago.edu!stuart
From: stuart@tartarus.uchicago.edu (Stuart A. Kurtz)
Newsgroups: comp.sys.mac.programmer
Subject: Desk Accessories, WaitNextEvent
Keywords: DAs WaitNextEvent
Message-ID: <4839@tank.uchicago.edu>
Date: 4 Aug 89 16:43:57 GMT
Sender: news@tank.uchicago.edu
Reply-To: stuart@tartarus.uchicago.edu (Stuart A. Kurtz)
Organization: Dept. of Comp. Sci., The University of Chicago
Lines: 50

I've had a few troubles with the interaction between DAs and my Application
Code.  As near as I can tell (look at the Finder), I'm not alone ...

My first problem has to do with DAs and keyboard equivalents for menu
items.  Say, for example, I have a "Close" item on the "File" menu with
keyboard equivalent clover-W.  Now, open a DA with the Option key (so that
the desk accessory is opened in the application layer, rather than the
DAHandler layer).  Most applications, including mine and including the
finder, would like to close the DA if it is front-most and the Close item
is selected from the File Menu.  If this is done the old-fashioned way,
i.e., by selecting Close using the mouse, there is no problem.  If, on the
other hand, you try to close it using clover-W, you get a SysBeep() and no
close.

Since I don't seem to get a recognizable event, I assume the implicit
SystemEvent() in WNE/GNE is feeding the event to the DA, and then coercing
it into a null event, even though the DA couldn't handle it.

I see two solutions: The right solution is to use the OSEvent Manager to
intercept clover-key's before they get handled by GNE/WNE (who knows if
this will work for WNE).  When I see such an event, I'll change
theEvent.what to app1 or something, and evade SystemEvent().  The second
solution is to ignore the problem, and hope it will go away in System 7.
Note that in system 6, this problem is more frequent than you might guess:
since DAs are always opened in the application layer when Multifinder isn't
running.

My second problem has to do with the sleep parameter of WNE.  The
"Programmer's Guide to Multifinder" claims that I don't have to worry about
calling SystemTask(), as WNE will handle it.  Unfortunately, this just
isn't so.  Consider the following fragment:

	WaitNextEvent(--,--,0xFFFFFFFF,--);

This is the sort of thing that's recommended if you don't need idle events.
Now, if you open the AlarmClock DA in the application, guess what?  Right,
and on the first guess!  It doesn't get updated.  Similarly (and more
seriously) , the Moire clock doesn't update either.

This is a bit harder to fix.  Right now I'm leaning towards some system
tuning parameters in a "Preferences..." dialog.  99.44% of the time,
sleeping for a second in the foreground and forever in the background will
be correct; but I'm fastidious enough to want to handle the other .56%
correctly.  [Which suggests an interesting question about Ivory Soap ...]

Stu
-------------------------------------------------------------------------
Stuart A. Kurtz                         Telephone: (312)-702-2493
Department of Computer Science          EMail:     stuart@cs.uchicago.edu
University of Chicago