Multithreading? Or the equivalent?
Mark
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?
Csaba Gabor
<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" <Mark...@gems.gov.bc.ca> wrote in message
news:4090...@obsidian.gov.bc.ca...
Brian Genisio
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
Martin Honnen
Mark wrote:
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/
Randy Webb
> 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/
Michael Winter
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.Wi...@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Csaba Gabor
news:opr7b1lh...@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
Michael Winter
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
Randy Webb
> On Sun, 2 May 2004 13:10:14 +0200, Csaba Gabor <ne...@CsabaGabor.com> wrote:
>
>> "Michael Winter" <M.Wi...@blueyonder.co.invalid> wrote in message
>> news:opr7b1lh...@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.