Preserved Topic: javascript has a fatal flaw - is there a way round? $Pages that link to <a href="https://ozoneasylum.com/backlink?for=8733" title="Pages that link to Preserved Topic: javascript has a fatal flaw - is there a way round?" rel="nofollow" >Preserved Topic: javascript has a fatal flaw - is there a way round?\$

Author	Thread
smonkey Paranoid (IV) Inmate From: Northumberland, England Insane since: Apr 2003	posted 06-28-2003 22:06 one thing I've noticed is that if you have a javascript that is set to do something at a particular event and then you start another piece of javascript using another event before the first has finished doing it's business then the first breaks. Can javascript only handle one event at a time?
Petskull Maniac (V) Mad Scientist From: 127 Halcyon Road, Marenia, Atlantis Insane since: Aug 2000	posted 06-28-2003 22:36 hmm... I've never had any problems of this sort... perhaps some code to go with that? Code - CGI - links - DHTML - Javascript - Perl - programming - Magic - http://www.twistedport.com ICQ: 67751342
Slime Lunatic (VI) Mad Scientist From: Massachusetts, USA Insane since: Mar 2000	posted 06-28-2003 23:09 I think you must be mistaken. As long as a piece of code is continuous (basically, as long as it uses no setTimeout or setInterval calls to "wait"), it cannot be interrupted by another event. I suggest that you strip your code down, bit by bit, in order to come up with the smallest piece of code which will reliably reproduce the problem you're having. In the process, you'll probably either figure out what's wrong, or if not, you can post the code here, and as long as you've made it small enough, we should be able to help figure out what's wrong.
smonkey Paranoid (IV) Inmate From: Northumberland, England Insane since: Apr 2003	posted 06-29-2003 14:43 ok let me give you an example, i have no specific code to strip down but this is an example of something i've noticed many times. say you call a function using the body onload event - say this function is supposed to change the src of an img then say you click a null link that triggers another function, you'll find that the image never has it's src changed unless you waited for it happen the first time. maybe is a problem with body onload tho, it could be that if you interupt a loading page with a null link that it stops the loading of that page and hence the scripts that run when that page has completed.
Archonian Nervous Wreck (II) Inmate From: Sweden, Malmoe Insane since: Jan 2003	posted 06-29-2003 16:40 But if one was to have two functions that both uses setTimeout and are going to be run line by line. Then is there a way to wait for the first function to finish, and not start the second function?
bitdamaged Maniac (V) Mad Scientist From: 100101010011 <-- right about here Insane since: Mar 2000	posted 06-29-2003 22:40 I think you can do this. flag = false // you need to do this before you're test. flag = setTimeout('whatever()',3000); if (flag) wait(); Another way to do this is to set a global variable that you can turn on and off while waiting. By the way you can also use flag to kill a timeout that's currently paused clearTimout(flag); In response to smonkey's question. That example is actually a code issue (not a JS issue). What I do is this. loaded = false; function init() { ... // do whatever you want to do after the load here loaded = true; } function changeSRC() { if (loaded) { ... // change your image src } } <body onLoad="init()"> .:[ Never resist a perfect moment ]:. [This message has been edited by bitdamaged (edited 06-29-2003).]
Slime Lunatic (VI) Mad Scientist From: Massachusetts, USA Insane since: Mar 2000	posted 06-29-2003 23:23 quote: say you call a function using the body onload event - say this function is supposed to change the src of an img then say you click a null link that triggers another function, you'll find that the image never has it's src changed unless you waited for it happen the first time. As you guessed, this behavior is caused by the fact that clicking a hyperlink causes Internet Explorer to stop loading the current page, and the onload event, I think, is not called. The solution is to be careful about how you attach scripts to hyperlinks. Instead of doing this: <a href="javascript:stuff;">...</a> do this: <a href="" onclick="stuff; return false;">...</a> And Internet Explorer will not consider the hyperlink to have truly been followed when it's clicked on. By the way, don't get me wrong - using setTimeout does not make a function vulnerable to any sort of "interruption." It's just that it is possible for code to execute after the current code being executed finishes, and before the future code called by setTimeout starts.
trib Paranoid (IV) Inmate From: Den Haag, Netherlands Insane since: Sep 2002	posted 06-30-2003 11:20 I had the same problem many times in the past .. Nowadays, I set a variable loaded=false, as the very first instruction in my script, right as near to the top of the page as it's possible to get ... then I set onLoad=init ... and onResize = init ... (if I'm using resizeable contents) Init() is where I set up everything I might need throughout the proggie - calling functions to define objects and initialise them etc. etc. ... then as the very last thing in my init() function I set loaded=true. Finally, EVERY single function on my page which can be called by an event begins with ... if (!loaded) { return}; (edit ... Whoops - Sorry - I just repeated BitDamaged's response somewhat ... I didn't read it thoroughly enough) Bug-free software only exisits in two places A programmer's mind and a salesman's lips [This message has been edited by trib (edited 06-30-2003).]
hyperbole Paranoid (IV) Inmate From: Madison, Indiana, USA Insane since: Aug 2000	posted 07-02-2003 07:27 I have run into this problem in the past. It can occur not only with onLoad, but also if the user selects a link or presses a key combination that takes the browser away from the executing function. When the interupting function completes, it returns control to the browser, not to the interupted function. The only way I have found around this problem is to disable the events that would cause the browser to interupt a function when the function starts to execute and re-enable them when the function completes. This gets to be kind of tricky programming because you can cause real probles for yourself if you forget to re-enable a keypress of mouse event at the end of the function. -- not necessarily stoned... just beautiful.

Preserved Topic: javascript has a fatal flaw - is there a way round?\$

Author

Thread

smonkey
Paranoid (IV) Inmate

From: Northumberland, England
Insane since: Apr 2003

posted 06-28-2003 22:06

one thing I've noticed is that if you have a javascript that is set to do something at a particular event and then you start another piece of javascript using another event before the first has finished doing it's business then the first breaks. Can javascript only handle one event at a time?

Petskull
Maniac (V) Mad Scientist

From: 127 Halcyon Road, Marenia, Atlantis
Insane since: Aug 2000

posted 06-28-2003 22:36

hmm... I've never had any problems of this sort...

perhaps some code to go with that?

Code - CGI - links - DHTML - Javascript - Perl - programming - Magic - http://www.twistedport.com
ICQ: 67751342

Slime
Lunatic (VI) Mad Scientist

From: Massachusetts, USA
Insane since: Mar 2000

posted 06-28-2003 23:09

I think you must be mistaken. As long as a piece of code is continuous (basically, as long as it uses no setTimeout or setInterval calls to "wait"), it cannot be interrupted by another event. I suggest that you strip your code down, bit by bit, in order to come up with the smallest piece of code which will reliably reproduce the problem you're having. In the process, you'll probably either figure out what's wrong, or if not, you can post the code here, and as long as you've made it small enough, we should be able to help figure out what's wrong.

smonkey
Paranoid (IV) Inmate

From: Northumberland, England
Insane since: Apr 2003

posted 06-29-2003 14:43

ok let me give you an example, i have no specific code to strip down but this is an example of something i've noticed many times.

say you call a function using the body onload event - say this function is supposed to change the src of an img

then say you click a null link that triggers another function, you'll find that the image never has it's src changed unless you waited for it happen the first time.

maybe is a problem with body onload tho, it could be that if you interupt a loading page with a null link that it stops the loading of that page and hence the scripts that run when that page has completed.

Archonian
Nervous Wreck (II) Inmate

From: Sweden, Malmoe
Insane since: Jan 2003

posted 06-29-2003 16:40

But if one was to have two functions that both uses setTimeout and are going to be run line by line. Then is there a way to wait for the first function to finish, and not start the second function?

bitdamaged
Maniac (V) Mad Scientist

From: 100101010011 <-- right about here
Insane since: Mar 2000

posted 06-29-2003 22:40

I think you can do this.

flag = false // you need to do this before you're test.
flag = setTimeout('whatever()',3000);

if (flag) wait();

Another way to do this is to set a global variable that you can turn on and off while waiting.

By the way you can also use flag to kill a timeout that's currently paused

clearTimout(flag);

In response to smonkey's question. That example is actually a code issue (not a JS issue). What I do is this.

loaded = false;

function init() {
... // do whatever you want to do after the load here
loaded = true;
}

function changeSRC() {
if (loaded) {
... // change your image src
}
}
<body onLoad="init()">

.:[ Never resist a perfect moment ]:.

[This message has been edited by bitdamaged (edited 06-29-2003).]

Slime
Lunatic (VI) Mad Scientist

From: Massachusetts, USA
Insane since: Mar 2000

posted 06-29-2003 23:23

quote:
say you call a function using the body onload event - say this function is supposed to change the src of an img

then say you click a null link that triggers another function, you'll find that the image never has it's src changed unless you waited for it happen the first time.

As you guessed, this behavior is caused by the fact that clicking a hyperlink causes Internet Explorer to stop loading the current page, and the onload event, I think, is not called.

The solution is to be careful about how you attach scripts to hyperlinks. Instead of doing this:

<a href="javascript:stuff;">...</a>

do this:

<a href="" onclick="stuff; return false;">...</a>

And Internet Explorer will not consider the hyperlink to have truly been followed when it's clicked on.

By the way, don't get me wrong - using setTimeout does not make a function vulnerable to any sort of "interruption." It's just that it is possible for code to execute after the *current* code being executed finishes, and before the *future* code called by setTimeout starts.

trib
Paranoid (IV) Inmate

From: Den Haag, Netherlands
Insane since: Sep 2002

posted 06-30-2003 11:20

I had the same problem many times in the past .. Nowadays, I set a variable loaded=false, as the very first instruction in my script, right as near to the top of the page as it's possible to get ...

then I set onLoad=init ...
and onResize = init ... (if I'm using resizeable contents)

Init() is where I set up everything I might need throughout the proggie - calling functions to define objects and initialise them etc. etc. ... then as the very last thing in my init() function I set loaded=true.

Finally, EVERY single function on my page which can be called by an event begins with ... if (!loaded) { return};

(edit ... Whoops - Sorry - I just repeated BitDamaged's response somewhat ... I didn't read it thoroughly enough)

Bug-free software only exisits in two places
A programmer's mind and a salesman's lips

[This message has been edited by trib (edited 06-30-2003).]

hyperbole
Paranoid (IV) Inmate

From: Madison, Indiana, USA
Insane since: Aug 2000

posted 07-02-2003 07:27

I have run into this problem in the past. It can occur not only with onLoad, but also if the user selects a link or presses a key combination that takes the browser away from the executing function. When the interupting function completes, it returns control to the browser, not to the interupted function.

The only way I have found around this problem is to disable the events that would cause the browser to interupt a function when the function starts to execute and re-enable them when the function completes. This gets to be kind of tricky programming because you can cause real probles for yourself if you forget to re-enable a keypress of mouse event at the end of the function.

-- not necessarily stoned... just beautiful.