Getting event information in IE.

I am dynamically adding rows to a table, and each row have a button which
removes it.
I have successfully implemented this for mozilla but I'm having troubles
with IE, here is how I did it:

Each new row's id is an index number, each button's name is the row's id,
and I'm adding this function as the click event listener for the button:

function removeline(event){
var row=document.getElementById("row" + event.target.name);
var tbody=document.getElementById("items");
var olds=tbody.style.display;
tbody.style.display="none";
tbody.removeChild(row);
tbody.style.display=olds;
}

I'm adding it this way:

var newbutton=document.createElement("INPUT");
newbutton.type="button";
newbutton.value="Remove";
newbutton.id=rowcount;
newbutton.name=rowcount;
if(navigator.userAgent.match("MSIE")) // for IE compatibility
newbutton.attachEvent("onclick",removeline);
else
newbutton.addEventListener("click",removeline,fals e);


But IE doesn't pass nothing as a parameter for removeline().
Any suggestions?

Thanks,
-Amir.
--
Remove the 'dont_spam_me' and the dashes before mailing me.

re: Getting event information in IE.

On Thu, 26 Feb 2004 18:58:22 +0200, Amir Hardon
<ha-dont_spam_me-rdon@actcom.co.il> wrote:
[color=blue]
> I am dynamically adding rows to a table, and each row have a button which
> removes it.
> I have successfully implemented this for mozilla but I'm having troubles
> with IE, here is how I did it:
>
> Each new row's id is an index number, each button's name is the row's id,
> and I'm adding this function as the click event listener for the button:
>
> function removeline(event){
> var row=document.getElementById("row"
> + event.target.name);
> var tbody=document.getElementById("items");
> var olds=tbody.style.display;
> tbody.style.display="none";
> tbody.removeChild(row);
> tbody.style.display=olds;
> }
>
> I'm adding it this way:
>
> var newbutton=document.createElement("INPUT");
> newbutton.type="button";
> newbutton.value="Remove";
> newbutton.id=rowcount;
> newbutton.name=rowcount;
> if(navigator.userAgent.match("MSIE")) // for IE compatibility
> newbutton.attachEvent("onclick",removeline);
> else
> newbutton.addEventListener("click",removeline,fals e);
>
>
> But IE doesn't pass nothing as a parameter for removeline().
> Any suggestions?
>
> Thanks,
> -Amir.[/color]



--
Michael Winter
M.Winter@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

re: Getting event information in IE.

[Apologies if another post is received - it should have been cancelled]

On Thu, 26 Feb 2004 18:58:22 +0200, Amir Hardon
<ha-dont_spam_me-rdon@actcom.co.il> wrote:
[color=blue]
> I am dynamically adding rows to a table, and each row have a button which
> removes it.
> I have successfully implemented this for mozilla but I'm having troubles
> with IE, here is how I did it:
>
> Each new row's id is an index number, each button's name is the row's id,
> and I'm adding this function as the click event listener for the button:[/color]

[snip]
[color=blue]
> if(navigator.userAgent.match("MSIE")) // for IE compatibility
> newbutton.attachEvent("onclick",removeline);
> else
> newbutton.addEventListener("click",removeline,fals e);[/color]

This is a very bad way of adding the event. You should never use the
userAgent string to determine what methods are used. Use feature detection
instead:

if( newbutton.addEventListener ) {
newbutton.addEventListener('click',removeline,fals e);
} else if( newbutton.attachEvent ) {
newbutton.attachEvent('onclick',removeline);
}

You should make sure that you use feature detection before accessing
methods and properties, particularly those of DOM components. IE has
relatively poor support and feature testing is the most reliable way to
determine when fallbacks are necessarily. Using the userAgent string might
group well-behaved (read: standards implementing) browsers with IE, which
would prevent you from taking advantage of their features.
[color=blue]
> But IE doesn't pass nothing as a parameter for removeline().
> Any suggestions?[/color]

The problem is that IE, unlike most other browsers, doesn't pass an event
object to event listeners. Instead, event data is held in a global event
object. A further problem is that IE's event object doesn't use the same
properties as the DOM interface, or Netscape's object (from JS v1.3). Your
handler would have to be written:

function removeline(evt){
var rowSuffix;

evt = evt || window.event;
if( evt.target ) {
rowSuffix = evt.target.name;
} else if( evt.srcElement ) {
rowSuffix = evt.srcElement.name;
}

var row=document.getElementById("row" + rowSuffix);
var tbody=document.getElementById("items");
var olds=tbody.style.display;
tbody.style.display="none";
tbody.removeChild(row);
tbody.style.display=olds;
}

Hope that helps,
Mike

--
Michael Winter
M.Winter@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

re: Getting event information in IE.

Michael Winter <M.Winter@blueyonder.co.invalid> writes:
[color=blue]
> The problem is that IE, unlike most other browsers, doesn't pass an
> event object to event listeners.[/color]

Actually it does when you attech the listener with attachEvent.
Try this.
document.body.attachEvent("onclick",
function(evt){alert(evt.srcElement.tagName);});
in IE 5+ (couldn't get IE 4 to work well enough to test it there).

It doesn't pass the event as argument when you assign the handler
directly to document.body.onclick.

Now that attachEvent has started to look usefull, it's time to mention
the shortcomming: The value of "this" when the handler is called is
the global object, not the object that the handler is attached to
(also unlike assigning to onclick, and unlike how other browsers
treat addEventListener - even if it is not part of the DOM spec.).

Otherwise I agree.
/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: Getting event information in IE.

On Thu, 26 Feb 2004 21:34:33 +0100, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote:
[color=blue]
> Michael Winter <M.Winter@blueyonder.co.invalid> writes:
>[color=green]
>> The problem is that IE, unlike most other browsers, doesn't pass an
>> event object to event listeners.[/color]
>
> Actually it does when you attech the listener with attachEvent.[/color]

It does? Well I'll be...

I assumed that as it doesn't when you use the event properties, it
wouldn't with attachEvent - a sensible connection, I thought.

I wonder why the differences occur. Could it be because attachEvent allows
multiple, concurrent listeners?
[color=blue]
> Try this.
> document.body.attachEvent("onclick",
> function(evt){alert(evt.srcElement.tagName);});
> in IE 5+ (couldn't get IE 4 to work well enough to test it there).[/color]

According the MS' DHTML reference, attachEvent was implemented in IE 5. IE
4 will still depend on assignment to the event properties. The OP's code
should probably be extended to:

if( newbutton.addEventListener ) {
newbutton.addEventListener('click',removeline,fals e);
} else if( newbutton.attachEvent ) {
newbutton.attachEvent('onclick',removeline);
} else {
newbutton.onclick = removeline;
}

if support for earlier browsers is required.
[color=blue]
> Now that attachEvent has started to look usefull, it's time to mention
> the shortcomming: The value of "this" when the handler is called is
> the global object, not the object that the handler is attached to
> (also unlike assigning to onclick, and unlike how other browsers
> treat addEventListener - even if it is not part of the DOM spec.).[/color]

That is quite a shortcoming. I realise that one can simply use
event.srcElement, but this is so much more convenient. Is it mentioned
anywhere in the references, or something that you know through experience?

Mike


[OT]

I always wanted to know why MS even decided to use a single, global event
object. Do browsers use a threaded model to process events, rather than a
queue? Is there any advantage - not necessarily speed, but responsiveness
perhaps - after weighing in the added overhead? If so, IE makes that very
difficult as more development effort would be required in order to make
sure that an event read the correct data.

[More OT nonsense]

I like this quote from the attachEvent method description:

"If you attach multiple functions to the same event on the same
object, the functions are called in random order, immediately
after the object's event handler is called."

It's somewhat ambiguous. Functions are called in a random order. I know
it's the same with DOM listeners, but a better wording could have been
used. It also appears that functions added with attachEvent aren't event
handlers for the object and something else is, but what?

Finally, I like how references are called pointers in the MS docs.

--
Michael Winter
M.Winter@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

re: Getting event information in IE.

Michael Winter <M.Winter@blueyonder.co.invalid> writes:

[not setting "this"][color=blue]
> That is quite a shortcoming. I realise that one can simply use
> event.srcElement, but this is so much more convenient. Is it mentioned
> anywhere in the references,[/color]

Don't know, actually :)
[color=blue]
> or something that you know through experience?[/color]

Just something I found out when experimenting.
[color=blue]
> [OT]
>
> I always wanted to know why MS even decided to use a single, global
> event object.[/color]

Javascript was (and is) single threaded, and the intrinsic event
handlers could already refer to the current event by the name "event",
so I guess MS just thought that was as good an implementation as any.
Even simpler than passing the event, and almost always as good.
[color=blue]
> Do browsers use a threaded model to process events,
> rather than a queue?[/color]

Current browsers are definitly single threaded. Considering the target
audience (people who can put text together without knowing what they
are doing), avoiding concurrency issues is probably wise.
[color=blue]
> [More OT nonsense]
>
> I like this quote from the attachEvent method description:
>
> "If you attach multiple functions to the same event on the same
> object, the functions are called in random order, immediately
> after the object's event handler is called."
>
> It's somewhat ambiguous. Functions are called in a random order.[/color]

Yes, badly written. "Arbitrary" would be better than "random".
[color=blue]
> I know it's the same with DOM listeners, but a better wording could
> have been used. It also appears that functions added with
> attachEvent aren't event handlers for the object and something else
> is, but what?[/color]

Probably the intrinsic event/obj.onclick function.
[color=blue]
> Finally, I like how references are called pointers in the MS docs.[/color]

:)

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

re: Getting event information in IE.

On Thu, 26 Feb 2004 22:42:40 +0100, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote:
[color=blue]
> Michael Winter <M.Winter@blueyonder.co.invalid> writes:
>
> [not setting "this"][color=green]
>> That is quite a shortcoming. I realise that one can simply use
>> event.srcElement, but this is so much more convenient. Is it mentioned
>> anywhere in the references,[/color]
>
> Don't know, actually :)[/color]

I couldn't find it from a brief look around the various event-related
methods, so it might be written at a "guide" level (compare Netscape's
guides vs. references), rather than in the reference. I certainly hope
they mention it somewhere.

[snip]
[color=blue][color=green]
>> I always wanted to know why MS even decided to use a single, global
>> event object.[/color]
>
> Javascript was (and is) single threaded, and the intrinsic event
> handlers could already refer to the current event by the name "event",
> so I guess MS just thought that was as good an implementation as any.
> Even simpler than passing the event, and almost always as good.
>[color=green]
>> Do browsers use a threaded model to process events,
>> rather than a queue?[/color]
>
> Current browsers are definitly single threaded. Considering the target
> audience (people who can put text together without knowing what they
> are doing), avoiding concurrency issues is probably wise.[/color]

I suppose, from an abstract point of view, I always think of events as
concurrent. It just seems natural. I might also be my exposure to
interrupts on the x86 - I don't know. To introduce a queue system appears
to disrupt the spontaneity that an event-oriented system would imply.

That said, I can't think of a system on the PC at the moment (other than
low-level interrupts) that uses concurrent event handling. Windows is
built on a queue system. I remember that Java threads the Swing UI, but it
still uses queuing for events, doesn't it? I forget (I really need to get
back to Java). I haven't touched programming on Unix-based systems, yet so
I can't comment there. I don't have a Mac, either.
[color=blue][color=green]
>> It also appears that functions added with attachEvent aren't event
>> handlers for the object and something else is, but what?[/color]
>
> Probably the intrinsic event/obj.onclick function.[/color]

I think I meant that as a rhetorical question. I can't quite remember (I
blame my current fever).

I certainly guessed that the intrinsic event would be considered the
"event handler" in that context, but it might have been nice for Microsoft
to mention it, especially as functions added with attachEvent still
"handle" events.

Mike

--
Michael Winter
M.Winter@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)