| View previous topic :: View next topic |
| Author |
Message |
mikev
Joined: 21 Feb 2006
Posts: 1
|
| Posted: Tue Feb 21, 2006 12:52 pm determine which function is attached to an event |
|
|
How would I check if the function "foo" is the current handler for the onclick event? I have 2 onclick events and they need to alternate with each other, ie foo1 changes the event to foo2 and vice versa. Now I'm getting more complicated. I need foo1a to change to foo2a and back, and foo1b to change to foo2b and back. So when I'm cycling through elements with event handlers attached, how would I check what the current function is (foo1a/foo1b) so that I can change it to the next function (foo2a/foo2b)? What would the syntax look like for that?
if( htmlelement.onclick == "foo1a" ) htmlelement.onclick = function{ foo2a() };
else if( htmlelement.onclick == "foo1b" ) htmlelement.onclick = function{ foo2b() };
I imagine there's some way I could collapse all the foos into 1 function, but I'm hoping that this won't be too complicated to do it this way instead.
Thanks for any help!! |
|
|
kanenas
Joined: 14 Dec 2004
Posts: 193
|
| Posted: Sun Apr 23, 2006 1:08 am You've almost got it |
|
|
I'm assuming you don't want to change event listeners while handling an onclick event (else foo1a could set the listener to foo2a &c.).
Your code is close, but you don't want to use strings in the comparisons and you don't need the anonymous functons. You can also substitute a switch statement for if-elses.
Code: function switchOnclick(htmlelement) {
switch (htmlelement.onclick) {
case foo1a: htmlelement.onclick = foo2a;
break;
case foo2a: htmlelement.onclick = foo1a;
break;
case foo1b: htmlelement.onclick = foo2b;
break;
case foo2b: htmlelement.onclick = foo1b;
break;
}
}
Other options (such as using a single listener, using another attribute of htmlelement to keep track of the current listener's name [e.g. htmlelement.onclickName], using an object to handle switching [and keep track of the current listener], ...) are basically equivalent in that they keep state in parallel to the "htmlelement.onclick" attribute. Being equivalent, I'm including only one as an illustration.
Code: function switchOnclick(target, listener, alt) {
target.onclick = listener;
target.switchOnclick = function () { switchOnclick(target, alt, listener); }
}
switchOnclick(htmlelement, foo1a, foo2a);
// ...
//"htmlelement.switchOnclick();" swaps htmlelement's onclick listener.
htmlelement.switchOnclick();
Note this really does keep state in parallel; the variable "listener" in the anonymous function "htmlelement.switchOnclick" redundantly contains the same value as "target.onclick".
The nicest thing about this approach is that it's easy to associate what gets switched with what on a per-element (rather than a per-document or, as in the first example, per-switch function) basis (e.g. on another element, foo1a and foo1b could switch with each other). It's also easily adapted to take an arbitrary list of listeners and have the switch function cycle through them, or to deal with arbitrary events ("function switchListeners(target, onEvent ...)").
Yet another approach is to give a node a method to handle switching and a map of listeners to listeners. This has the advantage of allowing arbitrary listeners to switch to arbitrary listeners on any element, e.g.:
Code: /* suppose we wanted the switches defined by the network:
foo1a-->foo2a<--foo3a
^ ^ |
| | V
foo2b foo1b
*/
function switchOnclick(target, listener, switchMap) {
target.switchListeners = ...
//implementation left as an exercise to the reader
}
switchOnclick(htmlelement, foo3a, {foo1a: foo2a, foo2a: foo1b, foo1b: foo1a, foo3a: foo2a, foo2b: foo1a})
Note this isn't that much more useful than cycling through a list of listeners, as the switching of listeners will eventually reduce to a cycle ("(foo1a, foo2a, foo1b)" in the example).
If you use a DOM Event API (addEventListener & al.), you can't use the first approach (testing the onclick attribute) because AFAIK there is no way of querying whether or not a particular listener is set for an event on a node. If you use a DOM API, I recommend the second approach, which uses anonymous functions and closures to keep state. |
|
|
| |
|
|
|