Is it possible to force re-avaluating/re-parsing of HTML?

[Paul Gorodyansky]

it should be

txtField.onfocus=myFunction; <- note no parenthesis.

Sorry...

I guess I did try that too some time ago - now I remember that I
made it to work when left just function name as you show now...

If I remember correctly, the problem then is with _parameters_ -
how to provide them if I can write just a name of a function?

Because most fo the functions do need them, for example

onKeyDown='Kbd_OnOff(this, event)'

 

[Ian Collins]

I guess I did try that too some time ago - now I remember that I
made it to work when left just function name as you show now...

If I remember correctly, the problem then is with _parameters_ -
how to provide them if I can write just a name of a function?

Because most fo the functions do need them, for example

onKeyDown='Kbd_OnOff(this, event)'

event is always available in an event handler, either as a parameter
(newer browsers) or window.event (IE). Anything else (like an object to
use) can be bound to the event target.

 

[Paul Gorodyansky]

event is always available in an event handler, either as a parameter

it's my point - if we can NOT have any parameters - in the case of
txtField.onfocus=myFunction;

where there are no parameters can be used - then this method of adding
a handler is not good... Am I missing something?

off-topic -

Anything else (like an object to use) can be bound to the event target.

Just curious - say I used another method of adding a handler -
one that lets me use parameters (like outerHTML) and I sent (event) -
how them can I get "object to use"?
That is, are you saying that instead of
<textarea onKeyDown='Kbd_OnOff(this, event)' ...
I can use
<textarea onKeyDown='Kbd_OnOff(event)' ...
i.e. without 'this' as a parameter
and then somehow get a hold of that textarea object from inside
that function without such parameter?

 

[GLC]

For dynamically added event handlers; neither the event nor the element
triggering the event NEED to be passed.
I use Keith Gaughan's EventManager.

'tmpImg' is a refence to an image element.
'saveItem' is a refence to a function, see below.
To add an event handler: EventManager.Add(tmpImg, "click", saveItem,
false);
Then in the called function:
function saveItem(e){
// get target button
var targ;
if (!e) var e = window.event;
if (e.target) targ = e.target;
else if (e.srcElement) targ = e.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;


'e' is the event object, if it isn't automatically passed in, then it
is set.
'targ' is the element triggering the event.

 

[Paul Gorodyansky]

For dynamically added event handlers; neither the event nor the element
triggering the event NEED to be passed.
...
if (!e) var e = window.event;

^^^^^^^^^^^^
and

event is always available in an event handler, either as a parameter
(newer browsers) or window.event (IE).

So is your (Keith's) solution "IE-only"?

 

[GLC]

No, it is not IE only.
e is passed in as a parameter for non-IE browsers.
That line checks if e exists before using the IE only windows.event.

 

[Paul Gorodyansky]

No, it is not IE only.
e is passed in as a parameter for non-IE browsers.
That line checks if e exists before using the IE only windows.event.

Then it's a contradiction where it's a MUST to have parameter or not:

e is passed in as a parameter for non-IE browsers.
and

For dynamically added event handlers; neither the event nor the element
triggering the event NEED to be passed.

?

 

[GLC]

I apologize for my incoherent blabber.
I meant that the event object does not have to be specified or passed
in.
But, you are correct that the function definition must include a
parameter to receive the event if it IS passed in, which is the case
with non-IE browsers.
Thus, in my example where I am using a function reference to attach an
event handler, I am not including a parameter, because one cannot be
used for function references; and yet, the function definition does
have a parameter, which may or may not be used depending on the
browser.

Event handling and asynchronous function calls are so easy to
understand, I am surprise we are even having this discusion. ;-) j/k

 

[Paul Gorodyansky]

I apologize for my incoherent blabber.
I meant that the event object does not have to be specified or passed
in.
But, you are correct that the function definition must include a
parameter to receive the event if it IS passed in, which is the case
with non-IE browsers.
Thus, in my example where I am using a function reference to attach an
event handler, I am not including a parameter, because one cannot be
used for function references; and yet, the function definition does
have a parameter, which may or may not be used depending on the
browser.

You mean, non-IE browsers would not midn the following?

1) No parameter (can not be)

txtControl.onclick=myFunction;

2) There is a parameter and my function magically knows that it's
event
function myFunction(evt) {...}

Right?

Aslo, Keith never wrote a demo/explanation for his package so I still
don't get how to obtain an object where the even handler is working
if there is no 'this' parameter.

 

[Paul Gorodyansky]

Just to clarify - the discussion is now around the fact that
one can add an evenhandler (we are talking cross-browser, not jsut iE)
by

txtControl.onfocus=myFunction;

but only with _that_ syntax, i.e. NO parameters.

It then contradicts with your (unless I am missing something) phrase
about non-IE browsers _passing_ the parameter:

?

 

[Paul Gorodyansky]

You mean, non-IE browsers would not mind the following?

1) No parameter (can not be)

txtControl.onclick=myFunction;

2) There is a parameter and my function magically knows that it's
event
function myFunction(evt) {...}

ad not say a variable that sets a color of my button?

 

[Ian Collins]

You mean, non-IE browsers would not midn the following?

1) No parameter (can not be)

txtControl.onclick=myFunction;

Parameters are irrelevant here, 'myFunction' is the function reference.

2) There is a parameter and my function magically knows that it's
event
function myFunction(evt) {...}

It doesn't magically know, it is passed when then event handler is called.

Modern browsers call event handling callbacks with an event object as
their parameter, IE calls them with window.event as the event object.

 

[Paul Gorodyansky]

Parameters are irrelevant here, 'myFunction' is the function reference.

It doesn't magically know, it is passed when then event handler is called.

Modern browsers call event handling callbacks with an event object as
their parameter, IE calls them with window.event as the event object.

So non-IE browser while looking at that function definition - say
function myF(parA, parB, parC)

ALWAYS assumes that parA is event
and in the 'body' of that function I can use say

if (parA.ctrlKey)
return true;

?

Then it _is_ a magic So, always parameter #1? Or it's allowed
to have only one parameter at that's it? And the assumption that
it's event ?

Or you are saying that NO parameters are needed in the function
_definition_ - just

function myF()
{
}

and event is a pre-set, special name that can be used
like this

if (event.ctrlKey)
return true;

?

Presently I have say (event is 2nd parameter)

<textarea .... onkeypress=vkb_changeKey (this, event)

with parameters being set and used like this:

function vkb_changeKey (txtControl, evt)
{
if (evt.ctrlKey)
return true;
}

**********************************

So you guys are saying that it's possible to do the same

by

txtObject.onkeypress=vkb_changeKey;

and use some other methods for getting hold of text Object
(with the lcuk of 'this' as a parameter)
and use some other methods of using event ?

 

[Ian Collins]

So non-IE browser while looking at that function definition - say
function myF(parA, parB, parC)

ALWAYS assumes that parA is event
and in the 'body' of that function I can use say

if (parA.ctrlKey)
return true;

?

Then it _is_ a magic So, always parameter #1? Or it's allowed
to have only one parameter at that's it? And the assumption that
it's event ?

Do you have a book on JavaScript? If not, I'd recommend David
Flanagan's "JavaScript The Definitive Guide" where all these concepts
are explained.

 

[Paul Gorodyansky]

Do you have a book on JavaScript? If not, I'd recommend David
Flanagan's "JavaScript The Definitive Guide" where all these concepts
are explained.

Thanks, I'll do that - before I just used Web materials - thinking,
"if I know how to program in C or C++ then I can program in JavaScript
especailly because it's a _hobby_ (Virtual Keyboard) -
by just looking at Web examples and FAQ".

Kind of worked

But it looks like now it's time for learning more deep concepts...

 

[Ian Collins]

Thanks, I'll do that - before I just used Web materials - thinking,
"if I know how to program in C or C++ then I can program in JavaScript
especailly because it's a _hobby_ (Virtual Keyboard) -
by just looking at Web examples and FAQ".

That (C and C++) is my background as well and it took me a while to
break loose of the shackles imposed by a strongly typed, class
inheritance mindset.

Kind of worked

But it looks like now it's time for learning more deep concepts...

In the case of the above book, 590 well written pages of them

 

[Paul Gorodyansky]

Hi,

...
To add an event handler: EventManager.Add(tmpImg, "click", saveItem,
false);
Then in the called function:
function saveItem(e){
// get target button
var targ;
if (!e) var e = window.event;
if (e.target) targ = e.target;
else if (e.srcElement) targ = e.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;
...

Thanks, it works - if it's just a function that I want to have in a new
eventhandler added to object, but I can not figure out what to do
if it's not

<textarea onkeypress=myFunction(this, event)

but several things like (what to do with return ?):


a)
<textarea onkeypress={myFunction(this, event);x=f2(this);return false;}

or

b)
<textarea onkeypress={ return myFunction(this, event); }

 

[GLC]

In my opinion you should have a new function that combines the three
calls into one:

function myNewFunction(e){
// get event triggerer
var targ;
if(!e) var e = window.event;
if (e.target) targ = e.target;
else if (e.srcElement) targ = e.srcElement;
if (targ.nodeType == 3) // defeat Safari bug
targ = targ.parentNode;

myFunction(targ, e); // *** from your example
x=f2(targ); // from your example ***

// since returning false will probably not stop the event from
propagating
// or bubbling up we cancel the event
// - from http://www.quirksmode.org/js/events_order.html
e.cancelBubble = true;
if (e.stopPropagation) e.stopPropagation();
}

Then attach the new function as the keypress event handler.
I am assuming that 'x' is a global variable and that in your 'a'
example it would be attached to more than one textarea element/object.

 

[Paul Gorodyansky]

Hi,

I am assuming that 'x' is a global variable and that in your 'a'
example it would be attached to more than one textarea element/object.
Right.

In my opinion you should have a new function that combines the three
calls into one:

Good idea, thanks!

So the only thing remains unclear to me - what to do with the things
(by Martin Honnen -
http://www.faqts.com/knowledge_base/view.phtml/aid/1661 )

where a function could return either true or false
and _it matters_ - how to have return working?

(1)
onkeypress="return changeKey(this, event);">



or often there is a series of functions and then - return
statement (especially, if it's HREF simulation a button -
return false; prevents going to an URL):

Even if I combine all functions into one - what to do with
return ?

(2)
onkeypress="fCombined(e); return false;">

 

[GLC]

The whole point of returning a false is to stop the event from
"bubbling up"
So when you capture a keypress, and change what is being inserted, it
does not go ahead and insert the keypressed also.
For instance:
A textarea with an event handler has focus.
The user presses the 'a' key.
The event gets fired, captures the 'a' and the function inserts 'A'
into the textarea.
Then the event "bubbles up" and the browser inserts 'a' into the
textarea.

To prevent this senario, the event must be cancelled.
We have already accomlished what we wanted and no other handling needs
to occur, not even on the part of the browser.
So these lines are added, instead of returning false:
e.cancelBubble = true; // IE specific
if (e.stopPropagation) e.stopPropagation(); // won't work on IE
Or, skip the lines if the event is to continue propagating, like
returning true.