Yup, John's right. I've banged my head against the problem of queueing javascript events for years, and I'm convinced it's just not possible. This is partially because js objects on IE are particularly weird, as John points out, but also because event objects are "active" in the sense that their state can be modified to provide feedback to the system (cancel, preventDefault, etc). This statefulness becomes meaningless outside of the context in which they are originally fired.
On Sun, Sep 6, 2009 at 10:57 PM, John Tamplin <j...@google.com> wrote: > On Sun, Sep 6, 2009 at 2:00 PM, Ed <post2edb...@hotmail.com> wrote: > >> I think it would be possible if you use a kind of delayed-pipeline >> (pattern): holding on to an event till some condition is met before >> forwarding it....Example of the condition: till a maximum delay time >> is reached and/or the focus of the previous blur event is received. >> The advantage would be to receive the blur and focus event together in >> one event as a kind of paired event. So you can immediately find out >> which widget (if there is any) receives focus on a blur event... >> > > The problem is that even objects on IE are weird -- you can't save them > outside the context of the event handler they are passed to, and copying > doesn't work. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
