How to add extra action to onclick event ?

[abs]

My element:
<span onclick="alert( 'test')" id="mySpan">tes t</span>

Let's say that I don't know what is in this span's onclick event. Is it
possible to add another action to this element's onclick event ? I've tried
something like this:

oncl = document.getEle mentById('mySpa n').onclick
oncl = oncl + '\n;alert(\'add ed\')'
document.getEle mentById('mySpa n').onclick = oncl

And after this operation there'e no reaction to clicking on the <span>.
Anybody knows how to fix it ?

Best regards,
ABS

[VK]

> Bypass what?

I thought you couldn't do like obj.attachEvent ('onclick',
function(){aler t('Click!');})
But my test case appeared to be broken, it works, so sorry.

[VK]

I guess

foo = (arr[i].addEventListen er)?
arr[i].addEventListen er('click', extra, false) :
arr[i].attachEvent('o nclick', extra);

(where 'extra' is your function) would be enough in any context and no
problem with passing argument.

You have to remember that intrinsic handlers (<elm onevent="...") have
priority over programmed ones, so the function call goes like this:
1. intrinsic handlers
2. programmed handlers in random order (actually, this is the same
"organized disorder" as with key/value pairs in hash)

If you want to extend functionality based on the content of the
intrinsic handler, you may write an "EventSteal er" though it has more
relation to hacking rather than to development:

....
var objRef = e.target || event.srcElemen t;
var evtType = (e.type)? e.type : event.type;
var funRef = objRef['on'+evtType];
alert("On " + evtType + " this "+ objRef.tagName + " does this:\n\n" +
funRef.toString ();)
objRef['on'+evtType] = null;
alert("And now it does not!");

The code above is useless as it is, but you may study the function body
using RegExp and recompile it based on the study results.

[Michael Winter]

On 27/05/2005 07:17, abs wrote:

The problem with the code as posted is that createDispatche r doesn't
actually return anything. I apologise.

After the line:

Dispatcher.deta ch = detachDispatche r;

add:

return Dispatcher;

After that it 'works', but I'll be happier once I perform more tests.

And another question: will I be able to pass the parameter to added function
?

I'm afraid not, but that's how the event model itself works. The
function you pass to the add method will always receive one argument:
the event object. The difference between this and using the event
attributes in HTML is that the user agent creates this outer function
for you. However, you can easily call other functions within the
listener (just like alert in the example), passing any arguments you like.

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[abs]

Thank you guys for your posts. You helped me much.

ABS

[Richard Cornford]

VK wrote:

I guess

foo = (arr[i].addEventListen er)?
arr[i].addEventListen er('click', extra, false) :
arr[i].attachEvent('o nclick', extra);

(where 'extra' is your function) would be enough in any
context and no problem with passing argument.
Except on browsers that support neither mechanism, where the call to the
non-existent - attachEvent - method errors and kicks the code out of
execution.

<snip> var objRef = e.target || event.srcElemen t;
var evtType = (e.type)? e.type : event.type;
If - e - was not defined evaluating the expression - e.type - would
produce an error (again). It makes more sense to normalise the event
object once with - e = e || window.event -(and the like) and then act
only on that normalised event object.
var funRef = objRef['on'+evtType];
alert("On " + evtType + " this "+ objRef.tagName +
" does this:\n\n" + funRef.toString ();)
objRef['on'+evtType] = null;
alert("And now it does not!");

The code above is useless as it is,
Absolutly.
but you may study the function body using
RegExp and recompile it based on the study results.

The - toString - method of functions is specified as producing an
"implementa tion dependent" string. That string does not necessarily
correspond with the function's source code, and cannot necessarily be
re-interpreted as a functionally equivalent function. I.E. This strategy
should be expected to fail, and it certainly will in known existing
environments under some circumstances.

Richard.

[Michael Winter]

On 27/05/2005 12:20, Richard Cornford wrote:

[snip]

The - toString - method of functions is specified as producing an
"implementa tion dependent" string. That string does not necessarily
correspond with the function's source code,
Maybe, but I'd think not. After the specification states that "An
implementation-dependent representation of the function is returned", it
goes on to say that "This representation has the syntax of a
FunctionDeclara tion."

My interpretation is that the returned value should correspond with the
source code, but that the "placement of white space, line terminators,
and semicolons within the representation string is
implementation-dependent."

Of course, what should happen and what does happen in practice isn't
always the same.
and cannot necessarily be re-interpreted as a functionally equivalent
function.

Very true. There may be no way to reconstruct the scope chain, which may
render the function completely useless.

[snip]

Mike

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[Richard Cornford]

Michael Winter wrote:

On 27/05/2005 12:20, Richard Cornford wrote: <snip>

The - toString - method of functions is specified as
producing an "implementa tion dependent" string. That
string does not necessarily correspond with the
function's source code,

<snip> it goes on to say that "This representation has the syntax
of a FunctionDeclara tion." <snip> Of course, what should happen and what does happen
in practice isn't always the same.

<snip>

Yes, regular expression literals within function bodies have proved a
recurrent problem in this context because they are independently
interpreted into regular expression objects. It is not unusual to find a
regular expression object in a toString-ed function coming out as
[Object], or something similar. Which is a syntactically fine expression
in a regular expression literal context (being an array literal with one
element referring to the Object constructor), but will certainly not
produce the original functionality.

Chopping up function body strings and re-assembling the results has been
tired, but all that I have observed trying it (at least those that
actually test their code more than superficially) seem to rapidly
abandon the idea in favour of accumulating function references in the
type of code you presented.

Richard.

[Thomas 'PointedEars' Lahn]

VK wrote:

Bypass what?

I thought you couldn't do like obj.attachEvent ('onclick',
function(){aler t('Click!');})
But my test case appeared to be broken, it works, so sorry.

No. You both can and cannot use this. It depends on the JScript version
available on the client whether function expressions are considered a
syntax error or not. With new IEs, chances are high that it works.
PointedEars
--
Let us not judge others because of their religion, color or nationality.
We are all just human beings living together on this planet. (poehoe.de)