Don't fake it, replace it: have your composite widget implement HasValue<Date> (or whatever).
You really are best off avoiding having dom events as part of your public api. You'll note a trend in Gwt's widget set toward restricting dom events to implementation details, and the widgets themselves throwing custom semantic events. It's not yet universal, but keep an eye out. rjrjr On Monday, August 31, 2009, Ed <[email protected]> wrote: > > Hi, > > I need to support a single focus/blur of a group of widgets. > Please some advise on this? > > Examples: > 1) Date (Birtyday) field that consists of 3 small text boxes, that can > be filled in by the user. > 2) Date picker field: two date pickers to select a period. > > It's important that 1) and 2) form one widget with a single focus/blur > event. This is needed for further actions that depend on these > events. > For example: Form validation that occurs when a blur occurs. You don't > want to do a blur validation when the user is still filling in the > form and selects the other date field in 1) or the end date of the > date picker in 2). The blur will do validation and shows the > validation result. However, if the user is still busy filling in the > widget, you don't want to show some alert box. > > Implementation: I solved this with a WidgetGroupFocus object that > contains widgets and will control the focus/blur events. On a blur it > will hold the blur event and run a DeferredCommand to see if a focus > event occured on one of the containing widgets in the meantime. If > yes, the blur event is ignored, other wise the blur is distributed to > the subscribers. > > This has two major disadvantages: > 1) The global blur event will always be informed after the focus > event. As described above the blur event will be hold, to determine if > a focus event occurred on a widget that is outside the widget group. > In case this happens, the blur will be distributed after the focus > event (normally it's the other way around). However, I can live with > this... > > 2) The hold event can't be re-used. The hold blur event can't be > distributed as the same event after it has been hold as it might give > problems when the event is further processed, as GWT is already > processing other events. So GWT will throw exceptions like the ones > below when doing so (like expected). > In the past with the older event model this wasn't such an issue as > the listener didn't receive an event directly. > ---- > com.google.gwt.core.client.JavaScriptException: (Error): Member not > found. > number: -2147352573 > description: Member not found. > at com.google.gwt.dom.client.DOMImpl.eventGetType(Native Method) > --- > > Bottom line: the solution isn't so elegant so I am looking for a > better way of solving this. This might not be so difficult if it's > possible to be able to look on the event queue when receiving a blur > event. If the queue contains the upcoming focus event that caused the > blur event, the blur could be ignored.... (in my case) > But I have no idea how to do this, or if this is possible. > I played with the NativePreviewEvent to see if I could detect the > upcoming focus event that follows the blur event, but that has no > luck... > > Any idea's? > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
