Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!nic.MR.NET!indri!bin
From: bin@primate.wisc.edu (Brain in Neutral)
Newsgroups: comp.sys.mac.programmer
Subject: TransSkel2.01 comments
Message-ID: <130@indri.primate.wisc.edu>
Date: 10 Feb 89 20:24:49 GMT
Organization: UW-Madison Primate Center
Lines: 61


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