Prev: Ping
Next: onmouseleave Firefox equivalent
From: petermichaux on 18 Jun 2006 01:29

petermichaux(a)gmail.com wrote:
> Richard Cornford wrote:
> > petermichaux(a)gmail.com wrote:
> > <snip>
> > > I should point out that there is one bonus of using a flag
> > > to stop the tr onclick event handler from firing. If you have
> > > other listeners higher up the DOM than tr that you also want to
> > > have fire when either tr or td are clicked, then the flag will
> > > just bypass one level in the bubble up when td is clicked. If
> > > you stop the event altogether you can't do this, as far as I
> > > know.
> >
> > If you stop an event propagating then you stop it propagating, but that
> > does no necessitate the use of a global variable. The handler on the TR
> > could make an informed decision not to act when it received the event,
> > letting it carry on bubbling if necessary. It could, for example,
> > observe the that target of the event was either a TD, or contained
> > within an TD, that had a function assigned to the pertinent event
> > handler property, and so elect not to act.
>
> I'm working with a situation like this right now and can't find a clean
> way to make the type of decision you are suggesting. I have nested divs
> of various depth, some of which are listeners. It isn't as simple as
> looking to see if the target was within a TD. I suppose I could use a
> classname "listener" on each listening div. Then check if the event
> already bubbled through another "listener" before reaching the one
> currently handling the event. I don't really like the idea of using a
> classname for this. Seems like clutter.
>
> Is there a cross browser way to tag a particular event object as
> handled? It would be very clean if the event itself could carry
> information about which handlers have already seen the event.

I found a completely different approach to my problem. I'm curious
about tagging a property onto the event object but I think this object
is read only in Internet Explorer at least. Seems possible to add
properties to the event object in Firefox.

Thanks,
Peter

From: Richard Cornford on 18 Jun 2006 12:33
petermichaux(a)gmail.com wrote:
> petermichaux(a)gmail.com wrote:
<snip>
> ... . I'm curious about tagging a property onto the event
> object but I think this object is read only in Internet
> Explorer at least. ...
<snip>

In IE the events are not read-only. You can assign properties to an
event object and successfully read them back. The problem is that every
time you read the value of the global - event - property you get a
reference to a unique event object, so assigning values to priorities of
event objects cannot be used to pass values between event handlers on
IE, as each must read the global event property to get an event object,
and so each gets a different event object.

Still, if you must pass information in an event related way it would be
possible to add the properties to another object that is common to all
the event objects IE will create, such as the - srcElement - object.
Though if sets of event handlers need some private channels of
communication it would probably make more sense to implement that in the
script and avoid any reliance upon the ability to add properties to host
objects.

Richard.


From: petermichaux on 18 Jun 2006 15:01
Richard Cornford wrote:
>
> In IE the events are not read-only. You can assign properties to an
> event object and successfully read them back. The problem is that every
> time you read the value of the global - event - property you get a
> reference to a unique event object, so assigning values to priorities of
> event objects cannot be used to pass values between event handlers on
> IE, as each must read the global event property to get an event object,
> and so each gets a different event object.

Ahh. Ok. Thanks.

> Still, if you must pass information in an event related way it would be
> possible to add the properties to another object that is common to all
> the event objects IE will create, such as the - srcElement - object.
> Though if sets of event handlers need some private channels of
> communication it would probably make more sense to implement that in the
> script and avoid any reliance upon the ability to add properties to host
> objects.

I found a nice way to avoid adding properties to the event object.
Probably nicer than even if I could. Each event handler has a chance to
claim "first responder" status along the bubble up. When the event
reaches the "document" listener the first responder is called to
actually handle the event.

Thanks again for the information.

Peter

First  |  Prev  | 
Pages: 1 2 3 4
Prev: Ping
Next: onmouseleave Firefox equivalent