[comp.windows.x] Dispatching Events To Spring-Loaded Widgets

fred@hpcvlx.HP.COM (Fred Taft) (10/29/88)

Between the R2 and R3 intrinsics I have noticed a different behavior 
in the way button and key events are being dispatched to a spring 
loaded widget.

Under the R2 toolkit, if a button event was received, and the grab list
was empty, the event was ONLY dispatched to the widget the event occurred
in; if this widget, as a result of processing the event, added an exclusive,
spring loaded widget to the grab list, the event was not then dispatched to
the new spring loaded widget.

Under the R3 toolkit, this behavior has changed.  Now, after dispatching to
the original widget, the toolkit also looks to see if there are any exclusive
spring loaded widgets, and dispatches to them.  Since the original widget
added an exclusive spring loaded widget to the grab list, it also gets the
opportunity to process the event.

Was this new behavior intended, or did it sneak in accidentally?  It not
only has the potential of breaking certain types of widgets, but it also
can break applications!

swick@ATHENA.MIT.EDU (Ralph R. Swick) (11/01/88)

My reply to Fred's original posting to the Consortium mailing list:

To: Fred Taft <fred%hpcvxft@sde.hp.com>
Subject: Re: Dispatching events to spring loaded widgets 
In-Reply-To: Your message of Fri, 28 Oct 88 13:11:59 -0700.
             <8810282012.AA00318@hpcvxft.HP.COM> 
Organization: DEC/MIT Project Athena
Date: Fri, 28 Oct 88 17:52:37 EDT
From: Ralph R. Swick <swick@ATHENA.MIT.EDU>

The spec is not explicit on whether or not any of the routines that affect
the dispatching of events will have an impact on the _current_ event.

In the case you cite (registering a spring-loaded grab), it seems very
unlikely to me that the application would want the current event dispatched
to the new widget, and if it does then it should probably re-dispatch it
explicitly.

I suspect the modified behavior is therefore an oversight, but I invite
alternate opinions.