stuart@tartarus.uchicago.edu (Stuart A. Kurtz) (08/04/89)
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
jkjl@munnari.oz.au (John Keong-Jin Lim) (08/07/89)
In article <4839@tank.uchicago.edu> stuart@tartarus.uchicago.edu (Stuart A. Kurtz) writes: >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 ... >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. > >solution is to ignore the problem, and hope it will go away in System 7. I agree to this solution - don't waste mental energy on trying to bypass a design decision that apple made. > >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,--); > There is a tech note that says you mustnt set the sleep parameter above a certain magic number (100, 1000 ?) if you are running a pre-6.0 system. >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. > Glad you prefer my clock to superclock's ! This is a serious MF bug/feature problem. This is why Moire 2 is so jerky in some applications. The sleep param is set too high (ie Finder under MF). Moire 3 fixes it by patching WaitNextEvent and resetting the sleep longint to something shorter like 12 ticks when the screen saver is activated. WNE is not modified when the screensaver is inactive, so the clock wont be updated still i'm afraid. >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 ...] From my experience, the user doesnt care nor notice the 0.56% improvement in trivial things. Improve the user interface though and the rewards are immediate and obvious (ie. a progress bar for long computations is a waste of CPU time, but psychologically it makes the darn thing faster somehow). john lim Author of Moire ps : Moire 3 has been posted to info-mac and have asked the moderators to forward it to comp.binaries.mac. New features include improved user interface, better colour animation and control, configurable sleep/wake rects and run on shut down mode for large labs.