bin@primate.wisc.edu (Brain in Neutral) (02/11/89)
There are two slight divergences between TS 2.01 in C and TS 2.0 in Pascal, discussed below. Owen and I may converge in the near future. (By the way, Owen is really the one who did most of the work between TS 1.02 and 2.0, and you have him to thank for keeping on my case to get the C version done.) (i) Some have noted in the past a bug which allowed cmd-key equivalents to be passed to DA's twice when a DA window was in front. I was sent fixes, of which some didn't work (broke something else), and others which worked, but were more code-y than necessary. The problem originally arose from my method of testing whether an event had occurred or not, and assuming that GetNextEvent returning false meant a null event was returned (which is, after all, what IM says). In fact, GetNextEvent can return false, and you might well have some non-null event returned in your event record. This occurs, apparently, as follows. GetNextEvent, if it gets a non-null event, calls SystemEvent to see if the system wants to handle it. If so (for example, if it's a cmd-key equiv when a DA is in front), the system handles it, and GetNextEvent returns false. But the event record still has the key event. (And then TransSkel passes the event to the event-handler, because even "null" events should get passed to the dialog handler in case a dialog has TextEdit items, so the caret will blink...and finds a key event. And handles it - again.) This is now fixed. (ii) The port-setting model allows TransSkel to switch the port to a window that becomes active. That window is deactivated when another window becomes active, then the port switches again. This is fine (normally), because when the deactivate event occurs for the first window, the port has already been set there, so we know where it is and the code in it's handler to handles deactivates can assume so. There are cases, however, when you can get a deactivate event for a window with *no* preceding activate. If this happens, you can't make any assumptions about where the port it, so I chose to set the port on activates *and* deactivates. This is harmless for the normal case. Setting the port to a deactivating window doesn't matter if it's the last window (who care where the port is after it goes away?). If it's not the last window, some other window is coming active, and the port will be set properly then, anyway. How do you get a deactivate with no activate? initialize Put up window A Put up window B in front of A start event processing The first two events will be a deactivate for A, followed by an activate for B. In particular, the handler for A does not see an activate before it's told the window is deactivated. What logic would you use to determine where the port should be set at the point event processing commences? I chose to say "it doesn't matter" and set the port in TS whether an activate event is to activate *or* deactivate the window. Otherwise the programmer has to think about, for each program, which window of possibly many displayed will be the first to be deactivated (if any!) and set the port to it. My choice may be barbaric, however; comments welcome. Paul DuBois dubois@primate.wisc.edu rhesus!dubois bin@primate.wisc.edu rhesus!bin
dwb@Apple.COM (David W. Berry) (02/11/89)
In article <130@indri.primate.wisc.edu> bin@primate.wisc.edu (Brain in Neutral) writes: > >that GetNextEvent returning false meant a null event was returned (which is, >after all, what IM says). In fact, GetNextEvent can return false, and you >might well have some non-null event returned in your event record. This Well to quote Inside Mac, Page I-257: "If no event of any of the designated types is available, GetNextEvent returns a null event" and Page I-258: "Before reporting an event to your application, GetNextEvent first calls the Desk Manager function SystemEvent to see whether the system wants to intercept and respond to the event. If so, or if the event being reported is a null event, GetNextEvent returns a function result of FALSE;" While it doesn't explicitly say that the event will be turned into a null event, it also certainly doesn't imply that it will. Opinions: MINE, ALL MINE! (greedy evil chuckle) David W. Berry apple!dwb@sun.com dwb@apple.com 973-5168@408.MaBell
bin@primate.wisc.edu (Brain in Neutral) (02/11/89)
From article <25621@apple.Apple.COM>, by dwb@Apple.COM (David W. Berry): | Well to quote Inside Mac, Page I-257: | "If no event of any of the designated types is available, | GetNextEvent returns a null event" | | and Page I-258: | "Before reporting an event to your application, GetNextEvent first | calls the Desk Manager function SystemEvent to see whether the | system wants to intercept and respond to the event. If so, or if | the event being reported is a null event, GetNextEvent returns a | function result of FALSE;" | | While it doesn't explicitly say that the event will be turned into | a null event, it also certainly doesn't imply that it will. Yes, you're correct. But it's unclear. I realized that only afterward. In my opinion, the first quote contradicts the second. Paul DuBois dubois@primate.wisc.edu rhesus!dubois bin@primate.wisc.edu rhesus!bin