470,849 Members | 720 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

Multithreading? Or the equivalent?

Is there a way to achieve multithreading in JavaScript? I'm looking to
fetch a page into a div while allowing the user to interact with another
div. At some point the newly fetched page contents will be available to the
div that the user is working in but I don't want to cause unnecessary
blocking. I've thought of using frames (would prefer divs) plus timeouts
and checking for when a load completes. Does anyone have an idea of how
this could work?
Jul 23 '05 #1
8 3856
You can have a SCRIPT element
<SCRIPT type='text/javascript' id=comm1></SCRIPT>
and set the src attribute like so:
document.getElementById('comm1') = 'dome.js'

At the end of your dome.js file you should do a
window.setTimeout() of whatever function you have in
your original page waiting to be run.

I don't know that I'd call this multithreading though.
Also, you should figure out how you want to deal
with the server not returning the .js file in time/at all.

Csaba Gabor from Budapest

"Mark" <Ma*******@gems.gov.bc.ca> wrote in message
news:40******@obsidian.gov.bc.ca...
Is there a way to achieve multithreading in JavaScript? I'm looking to
fetch a page into a div while allowing the user to interact with another
div. At some point the newly fetched page contents will be available to the div that the user is working in but I don't want to cause unnecessary
blocking. I've thought of using frames (would prefer divs) plus timeouts
and checking for when a load completes. Does anyone have an idea of how
this could work?

Jul 23 '05 #2
Mark wrote:
Is there a way to achieve multithreading in JavaScript? I'm looking to
fetch a page into a div while allowing the user to interact with another
div. At some point the newly fetched page contents will be available to the
div that the user is working in but I don't want to cause unnecessary
blocking. I've thought of using frames (would prefer divs) plus timeouts
and checking for when a load completes. Does anyone have an idea of how
this could work?


Using setTimeout and setInterval, you can achieve a "multi-threaded"
effect. You need to make sure that nothing really blocks though.
You can use setInterval to do a periodic check if the data is ready, and
unschedule the interval once the task has completed.

You can use IFRAMES to load data in the background. You can set the
visibility to hidden, and the user will never see the page loading.
Once the page is loaded, you can set the visibility to show, and you
should be able to achieve what you want.

B

Jul 23 '05 #3


Mark wrote:
Is there a way to achieve multithreading in JavaScript? I'm looking to
fetch a page into a div while allowing the user to interact with another
div. At some point the newly fetched page contents will be available to the
div that the user is working in but I don't want to cause unnecessary
blocking. I've thought of using frames (would prefer divs) plus timeouts
and checking for when a load completes. Does anyone have an idea of how
this could work?


Client side JavaScript so far doesn't have any threading constructs but
it is event based and you can start loading an image for instance with
var img = new Image();
img.src = 'whatever.gif';
which the browser usually then does in a thread of its own and if you
have registered an onload event listener e.g
var img = new Image();
img.onload = function (evt) {
alert(this.src + ' loaded.');
};
img.src = 'whatever.gif';
then your event listener will be called once the image is loaded.

Some browsers like IE5+/Win and Netscape 6/7 and Mozilla based browsers
have special objects allowing you to make asynchronous HTTP requests and
set up event listeners to handle the response:
var httpRequest;
if (typeof ActiveXObject != 'undefined') {
httpRequest = new ActiveXObject('Msxml2.XMLHTTP');
}
else if (typeof XMLHttpRequest != 'undefined') {
httpRequest = new XMLHttpRequest();
}
if (httpRequest) {
//open(httpRequestMethod, URL, async)
httpRequest.open('GET', 'whatever.html', true);
httpRequest.onreadystatechange = function () {
if (httpRequest.readyState == 4) {
alert(httpRequest.responseText);
}
};
httpRequest.send(null);
}

That being demonstrated you should first consider making a site that
simply loads your page into an HTML iframe as that doesn't depend on
scripting being supported and enabled and should give you all the
advantages of interactivity and threaded request/response processing.
--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 23 '05 #4
Csaba Gabor wrote:
You can have a SCRIPT element
<SCRIPT type='text/javascript' id=comm1></SCRIPT>
and set the src attribute like so:
document.getElementById('comm1') = 'dome.js'


Assuming you meant document.getElementById('comm1').src instead, one
should still be careful about attempting to change the src attribute of
a script tag. It does not work in all browsers. It works (as in, it
loads the .js file), in IE5.0, 5.5, 6.0 Windows, IE5 Mac and Opera
7/Windows (at least version 7.23 does), but does *not* work in any other
browser that I am aware of. If you know of a browser/OS combination
where it works that is not listed, could you please let me know browser,
revision, and OS?


--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jul 23 '05 #5
On Wed, 28 Apr 2004 22:00:59 +0200, Csaba Gabor <ne**@CsabaGabor.com>
wrote:
You can have a SCRIPT element
<SCRIPT type='text/javascript' id=comm1></SCRIPT>
and set the src attribute like so:
document.getElementById('comm1') = 'dome.js'

At the end of your dome.js file you should do a
window.setTimeout() of whatever function you have in
your original page waiting to be run.

I don't know that I'd call this multithreading though.
Also, you should figure out how you want to deal
with the server not returning the .js file in time/at all.


In addition to what Randy said, you should be aware that the SCRIPT
element doesn't support an id attribute under any version of HTML or
XHTML. This has two implications:

1) You can't write valid HTML of any kind (unless you use your own DTD)
2) Strictly conforming browsers shouldn't return a SCRIPT element that has
a matching id.

Mike
Please don't top-post.

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #6
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
....
In addition to what Randy said, you should be aware that the SCRIPT
element doesn't support an id attribute under any version of HTML or
XHTML. This has two implications:

1) You can't write valid HTML of any kind (unless you use your own DTD)
2) Strictly conforming browsers shouldn't return a SCRIPT element that has
a matching id.


What about setting .src on document.scripts[#]?
Will this also not work in Netscape, etc.?

Csaba Gabor
Jul 23 '05 #7
On Sun, 2 May 2004 13:10:14 +0200, Csaba Gabor <ne**@CsabaGabor.com> wrote:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
...
In addition to what Randy said, you should be aware that the SCRIPT
element doesn't support an id attribute under any version of HTML or
XHTML. This has two implications:

1) You can't write valid HTML of any kind (unless you use your own DTD)
2) Strictly conforming browsers shouldn't return a SCRIPT element that
has a matching id.


What about setting .src on document.scripts[#]?
Will this also not work in Netscape, etc.?


I shouldn't think so. The scripts collection is a Microsoft-ism, though
Opera supports it too. The latest version of Mozilla (1.8a) doesn't, so I
doubt Netscape will.

There's nothing wrong with using getElementsByTagName() to achieve the
same effect, but Mozilla still isn't dynamic enough to load the new
script. It won't be the only one.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #8
Michael Winter wrote:
On Sun, 2 May 2004 13:10:14 +0200, Csaba Gabor <ne**@CsabaGabor.com> wrote:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:op**************@news-text.blueyonder.co.uk...
...
In addition to what Randy said, you should be aware that the SCRIPT
element doesn't support an id attribute under any version of HTML or
XHTML. This has two implications:

1) You can't write valid HTML of any kind (unless you use your own DTD)
2) Strictly conforming browsers shouldn't return a SCRIPT element
that has a matching id.

What about setting .src on document.scripts[#]?
Will this also not work in Netscape, etc.?


IE and Opera7 only, at the moment.

I shouldn't think so. The scripts collection is a Microsoft-ism, though
Opera supports it too. The latest version of Mozilla (1.8a) doesn't, so
I doubt Netscape will.
No, Netscape/Mozilla don't support changing the .src attribute (It
changes it, just doesn't load the .js file).

There's nothing wrong with using getElementsByTagName() to achieve the
same effect, but Mozilla still isn't dynamic enough to load the new
script. It won't be the only one.


www.hikksworld.com/loadJSFiles/index.html

Shows where it can/cant be dynamically loaded, and what method is used
to do it with. Mozilla can dynamically load a .js file via createElement.

While the chart does not show it (I removed it), dynamically loading can
be achieved (on a PC anyway) in NN4.xx by opening a layer, writing a
script tag to it, then closing it.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/
Jul 23 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

47 posts views Thread by mihai | last post: by
16 posts views Thread by Robert Zurer | last post: by
5 posts views Thread by sarge | last post: by
9 posts views Thread by tommy | last post: by
2 posts views Thread by Rich | last post: by
55 posts views Thread by Sam | last post: by
5 posts views Thread by sandy82 | last post: by
2 posts views Thread by Pradnya Patil | last post: by
7 posts views Thread by Ray | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.