Excellent write up John. +1 for the more accessible solution. Some other uses of EventPreview beyond popups:
* 3rd party dialogs (not extending PopupPanel) * Drag N Drop: mouse capture freezes the cursor in IE. If you want to change the cursor during a drag to indicate "Can't Drop" you have to go with Event Preview. * event tracing. Add an event preview at application startup, listen for a certain combination of keystrokes and start dumping events to the console. Currently breaks when popups / dialogs are show due to non-propagation of events up the chain. Another request for bubbling event preview: http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/4e33c2ec460ec988/d281219105a4efc6 Cheers, -= Mat On Wed, Dec 3, 2008 at 11:14 AM, Emily Crutcher <[EMAIL PROTECTED]> wrote: > What about deprecating the old DOM.addEventPreview and creating an > DOM.addPreviewHandler instead, where the PreviewEvent extends DomEvent and > has some specialized methods to stop the event from going down the GWT > preview event chain. > > On Wed, Dec 3, 2008 at 2:00 PM, Isaac Truett <[EMAIL PROTECTED]> wrote: >> >> > Other Solutions: >> > ============ >> > We considered passing the event preview down the existing stack of >> > EventPreview, which fixes the problem for more than just PopupPanels. >> > However, we think this approach is overkill because the problem really >> > doesn't manifest itself in other widgets. >> >> What about GlassPanel in the Incubator? Sounds like throwing a >> GlassPanel into the mix would break things since it isn't a subclass >> of PopupPanel and does it's own event previewing. --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
