By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,701 Members | 1,711 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,701 IT Pros & Developers. It's quick & easy.

Events

P: n/a
Hi everyone
I am currently confused about a piece of code that I have encountered:

Expand|Select|Wrap|Line Numbers
  1.  
  2. function handleKeyUp(e){
  3.  
  4. e = (!e) ? window.event : e; //get the event
  5. target = (!e.target) ? e.srcElement : e.target; //get the event's
  6. target
  7. if (target.nodeType == 3)
  8. target = target.parentNode;
  9.  
  10. if (e.charCode)
  11. code = e.charCode;
  12. else
  13. if (e.keyCode)
  14. code = e.keyCode;
  15. else
  16. if (e.which)
  17. code = e.which;
  18. else
  19. code = 0;
  20.  
  21. if (e.type == "keyup") {
  22. isKeyUpDownPressed = false;
  23.  
1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event
3) What's if (target.nodeType == 3)
target = target.parentNode;'
4) What does this piece of code do?
Nov 11 '08 #1
Share this Question
Share on Google+
11 Replies


P: n/a
disappearedng meinte:
Hi everyone
I am currently confused about a piece of code that I have encountered:

Expand|Select|Wrap|Line Numbers
  1. function handleKeyUp(e){
  2.     e = (!e) ? window.event : e; //get the event
Expand|Select|Wrap|Line Numbers
  1.  
  2. e = e || window.event;
  3.  
  4.         
  5.                     target = (!e.target) ? e.srcElement : e.target; //get the event's
  6.  
  7. target = e.target || e.srcElement;
  8.  
  9.         
  10.                 target
  11.     if (target.nodeType == 3)
  12.         target = target.parentNode;
  13.     if (e.charCode)
  14.         code = e.charCode;
  15.     else
  16.         if (e.keyCode)
  17.             code = e.keyCode;
  18.         else
  19.             if (e.which)
  20.                 code = e.which;
  21.             else
  22.                 code = 0;
  23.     if (e.type == "keyup") {
  24.         isKeyUpDownPressed = false;
  25.  
  26.  
>
1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event
e = e || window.event; will suffice.
If e is falsy (e.g. undefined), e will get a reference to window.event.
A necessity due to different event models in the various browser DOMs.
3) What's if (target.nodeType == 3)
target = target.parentNode;'
What it says: If the nodeType of the element that received the event is
3 (a text node), target will be re-assigned to the parentNode (normally
an element node).
4) What does this piece of code do?
A keyup listener, that tries to assign event target and key code to
global variables. And then another variable isKeyUpDownPressed is set to
false.
That's it. Pretty bad code and style.

Gregor
Nov 11 '08 #2

P: n/a
Gregor Kofler wrote:
disappearedng meinte:
>I am currently confused about a piece of code that I have encountered:

[code]
function handleKeyUp(e){

e = (!e) ? window.event : e; //get the event

e = e || window.event;
if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}

if (e)
{
// ...
}
> target = (!e.target) ? e.srcElement : e.target; //get the event's

target = e.target || e.srcElement;
*and*

if (target)
{
// ...
}
e = e || window.event; will suffice.
It won't.
If e is falsy (e.g. undefined), e will get a reference to window.event.
Iff type-converting that value to boolean does not throw an exception.
A necessity due to different event models in the various browser DOMs.
A beginning for handling that.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Nov 11 '08 #3

P: n/a
On Nov 11, 8:07 am, disappearedng <disappeare...@gmail.comwrote:
function handleKeyUp(e){
e = (!e) ? window.event : e; //get the event
target = (!e.target) ? e.srcElement : e.target; //get the event's

1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event
e here is the event object. Regular browsers will pass the event
object as the first argument to the event handler. Hence the
'handleKeyUp(e)' bit of code. But IE does it differently. It doesn't
pass anything to the event handler (which makes e undefined) instead
IE implements the event object as a global variable. Hence the
'window.event' thing. So, the code is checking to see if e is
'falsy' (and undefined IS falsy) and if it is, assign window.event to
e, otherwise assign e back to itself. Alternative ways to write this
are:

/* if e is falsy then e is window.event */
if (!e) {
e = window.event;
}

or my preferred way to write this

/* e is e or window.event */
e = e || window.event;

or some may even prefer

/* if e is undefined then e is window.event */
if (e == undefined) {
e = window.event;
}
3) What's if (target.nodeType == 3)
target = target.parentNode;'
Some browsers, particularly Webkit based browsers like Safari and
Nokia's web browser for the S60 platform sometimes triggers the event
on the text node rather than the node containing the text node. This
is not typically what you'd want. What you'd typically want is to know
which <divor <spanor <petc. is associated with the event. So if
we get a text node (nodeType 3) the real node we're interested in
would be its parent node.
Nov 11 '08 #4

P: n/a
slebetman wrote:
On Nov 11, 8:07 am, disappearedng <disappeare...@gmail.comwrote:
>function handleKeyUp(e){
e = (!e) ? window.event : e; //get the event
target = (!e.target) ? e.srcElement : e.target; //get the event's

1) Is e here an event?
2) what's the purpose of e = (!e) ? window.event : e; //get the event

e here is the event object. Regular browsers will pass the event object
as the first argument to the event handler.
s/Regular/Standards-compliant/
Hence the 'handleKeyUp(e)' bit of code. But IE does it differently. It
doesn't pass anything to the event handler (which makes e undefined)
instead IE implements the event object as a global variable.
No, it makes `event' a *property* of a Window object, which is in the scope
chain, to store a reference to an Event object.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Nov 11 '08 #5

P: n/a
On Nov 11, 12:12*am, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
slebetman wrote:
On Nov 11, 8:07 am, disappearedng <disappeare...@gmail.comwrote:
function handleKeyUp(e){
* * * * e = (!e) ? window.event : e; //get the event
* * * * target = (!e.target) ? e.srcElement : e.target; //get the event's
1) Is e here an event?
2) what's the purpose of * * * *e = (!e) ? window.event : e;//get the event
e here is the event object. Regular browsers will pass the event object
as the first argument to the event handler.

s/Regular/Standards-compliant/
Hence the 'handleKeyUp(e)' bit of code. But IE does it differently. It
doesn't pass anything to the event handler (which makes e undefined)
instead IE implements the event object as a global variable.

No, it makes `event' a *property* of a Window object, which is in the scope
chain, to store a reference to an Event object.
It's probably a very obvious answer, but you can guess that I'm new at
this.

I don't know if I'm missing the point here. Saying that it isn't a
global var but instead a property of the window object is 'only' a
conceptual mistake, right? I mean, the window's properties behave
pretty much like global vars, don't they?
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
Cheers

Gabriel Gilini
Nov 11 '08 #6

P: n/a
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
Gregor Kofler wrote:
>disappearedng meinte:
>>I am currently confused about a piece of code that I have encountered:

[code]
function handleKeyUp(e){

e = (!e) ? window.event : e; //get the event

e = e || window.event;

if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}
Why bother?
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.
If window.event doesn't exist, then
e = e || window.event;
will assign undefined to e, which is just as good as null.
if (e)
{
// ...
}
Again, if the above doesn't give us an event, then we are in a
non-standard compliant setting that we haven't ever heard of before.
Anybody creating a new non-standard compliant and non-IE compatible
setting deserves to see crashes.
>e = e || window.event; will suffice.

It won't.
For practical use, I'd say it would. Can you give a non-theoretical
example where it would fail?
>If e is falsy (e.g. undefined), e will get a reference to window.event.

Iff type-converting that value to boolean does not throw an exception.
That is possible. After all, it's a host object, so it can do anything.

/L
--
Lasse Reichstein Holst Nielsen
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Nov 11 '08 #7

P: n/a
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Gregor Kofler wrote:
>>disappearedng meinte:
I am currently confused about a piece of code that I have encountered:

[code]
function handleKeyUp(e){

e = (!e) ? window.event : e; //get the event
e = e || window.event;
if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}

Why bother?
Because it just isn't a two-browser or two-DOM world.
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.
If window.event doesn't exist, then
e = e || window.event;
will assign undefined to e, which is just as good as null.
From the event object reference not being passed as `e' does not follow that
`window.event' is viable.
> if (e)
{
// ...
}

Again, if the above doesn't give us an event, then we are in a
non-standard compliant setting that we haven't ever heard of before.
Anybody creating a new non-standard compliant and non-IE compatible
setting deserves to see crashes.
It is a really Bad Idea to try blaming users for the mistakes of the vendors
of their software. It is one thing not to support something; it is another
to break it willingly.
>>e = e || window.event; will suffice.
It won't.

For practical use, I'd say it would. Can you give a non-theoretical
example where it would fail?
No, but I rather program defensively now instead of having to deal with code
that breaks something somewhere later. Having bugs reported (which can also
be done in an automated way) is an entirely different animal than actually
embracing them.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Nov 11 '08 #8

P: n/a
Gabriel Gilini wrote:
Thomas 'PointedEars' Lahn wrote:
>slebetman wrote:
>>On Nov 11, 8:07 am, disappearedng <disappeare...@gmail.comwrote:
Hence the 'handleKeyUp(e)' bit of code. But IE does it differently.
It doesn't pass anything to the event handler (which makes e
undefined) instead IE implements the event object as a global
variable.
No, it makes `event' a *property* of a Window object, which is in the
scope chain, to store a reference to an Event object.

[...] I don't know if I'm missing the point here. Saying that it isn't a
global var but instead a property of the window object is 'only' a
conceptual mistake, right?
Such theoretical misconceptions can lead to very practical problems.
I/We have seen and discussed this numerous times before.
I mean, the window's properties behave pretty much like global vars,
don't they?
They don't. For one thing, provided the Window host object can be augmented
with user-defined properties (which should not be assumed), such properties
can be deleted. Global variables, as properties of the Global Object that
have the DontDelete attribute, can't.

This also isn't really news, and can (and should) readily be researched
before asking about it here again.

Please trim your quotes as observed here, and as described in the FAQ.

<http://jibbering.com/faq/#posting>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
Nov 11 '08 #9

P: n/a
On 11 nov, 17:47, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
I mean, the window's properties behave pretty much like global vars,
don't they?

They don't. *For one thing, provided the Window host object can be augmented
with user-defined properties (which should not be assumed), such properties
can be deleted. *Global variables, as properties of the Global Object that
have the DontDelete attribute, can't.
I see. Thank you for that.
This also isn't really news, and can (and should) readily be researched
before asking about it here again.

Please trim your quotes as observed here, and as described in the FAQ.

<http://jibbering.com/faq/#posting>
And sorry about this.

Cheers

Gabriel Gilini
Nov 11 '08 #10

P: n/a
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.dewrites:
>Gregor Kofler wrote:
>>disappearedng meinte:
I am currently confused about a piece of code that I have encountered:

[code]
function handleKeyUp(e){

e = (!e) ? window.event : e; //get the event
e = e || window.event;
if (!e)
{
e = (typeof window != "undefined"
&& typeof window.event != "undefined")
? window.event
: null;
}

Why bother?
Really.

The error condition will occur if testing in a non-browser environment.
That is not the case here.
If window doesn't exist, then I'd be willing to let the code fail
visibly. Something is so screwed up anyway, that I see no reason
to fail gracefully.
Yep.

Exit silently if window is undefined is a horrible way to handle that
error condition. Instead, a script error "window is undefined" would
indicate that (if it ever happened). This error will happen naturally,
should someone declare a window variable:-

function broken(){
var window;
window.alert();
}

The error that would occur is a much better alternative to silent
failure. Let the error occur, look at the stack and find the root cause.

Garrett

--
comp.lang.javascript FAQ <URL: http://jibbering.com/faq/ >
Nov 15 '08 #11

P: n/a
dhtml wrote:
Exit silently if window is undefined is a horrible way to handle that
error condition.
Not doing anything is better than breaking something.
Instead, a script error "window is undefined" would indicate that (if it
ever happened). This error will happen naturally, should someone declare
a window variable:-

function broken(){ var window; window.alert(); }

The error that would occur is a much better alternative to silent
failure. Let the error occur, look at the stack and find the root cause.
You miss the point. Users are not capable of debugging or understanding any
of the technobabble in the first place. So they will hold you (or your
customer) responsible for writing a bad program/making a bad Web site.
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Nov 16 '08 #12

This discussion thread is closed

Replies have been disabled for this discussion.