Javascript / Mouse Cursor / Possible "DoEvents" workaround
Richar...@pa-tech.com
I have a length javascript call ... and I am well aware of the
setInterval/setTimeout methods of breaking this call up to allow
visual content and/or changes to the mouse cursor to display
properly.
For other reasons, I'd prefer not to have to break up the call - and
I've stumbled onto another "potential" method of making this work.
Essentially, what it boils down to is that if do something like:
oDiv.style.visibility='visible'; // show a div with some sort of
"waiting" image
document.body.style.cursor = 'wait'; // change the mouse cursor
to the "hourglass"
... and then create/call a "specially constructed" (more to follow on
this) ActiveX control ... like follows ...
var oMyControl = new ActiveXObject("MyCode.MyControl");
... the screen/mouse will immediately update ... without ever having
to "exit" the javascript.
The ActiveX control is one that I wrote (using C++) ... and in it's
"FinalConstruct" method, I've put:
MSG msg ;
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
DispatchMessage(&msg);
}
... which is essentially the same as the VB "DoEvents" call.
My question to anyone out there is this ... I only have to support
Windows IE6 / IE7 clients ... with this assumption in mind ... is
there an "existing" ActiveX control / method that would already exist
on the client machines that I could use in place of "MyCode.MyControl"
- so that I don't have to have users install "MyCode"?
All help is greatly appreciated.
- Richard Gohs
Michael Harris
> Windows IE6 / IE7 clients ... with this assumption in mind ... is
> there an "existing" ActiveX control / method that would already exist
> on the client machines that I could use in place of "MyCode.MyControl"
> - so that I don't have to have users install "MyCode"?
The ScriptX component from www.meadroid.com has a wait method (in its free,
no-license-required subset) that lets you get the same effect with a wait(0)
call. Of course, it's not installed on Windows by default, but then I don't
know of any 'safe for scripting' ActiveX component that comes with Windows
that you could use.
--
Michael Harris
VK
> The ScriptX component fromwww.meadroid.comhas a wait method (in its free,
> no-license-required subset) that lets you get the same effect with a wait(0)
> call. Of course, it's not installed on Windows by default, but then I don't
> know of any 'safe for scripting' ActiveX component that comes with Windows
> that you could use.
Ever since my FAQ proposal at c.l.j.
http://groups.google.com/group/comp.lang.javascript/msg/b1470812c5e4d3b5
I was searching for an alternative workaround besides the "hard break"
over setTimeout but w/o success. Microsoft team made an amazingly good
job on pushing developers to the most dark corner on that :-) :-(
btw the mentioned in the FAQ proposal "soft break" idea doesn't work
of course, so don't waste your time on testing, that was just a
leftover of the brain storm.
With the "this" behavior when on exit from context methods do not
remember their owner any more programmers got stock for years between
Scilla and Haribda, and one of these should be really resolved by
producer some longest time ago, better the first one. It doesn't
matter that workarounds exist: why one need to drive by side roads
instead of highway?
P.S. What also amazes me is why all IE competitors keep neglecting
this problem? A heavy weight of bad habits?
VK
> P.S. What also amazes me is why all IE competitors keep neglecting
> this problem? A heavy weight of bad habits?
I am thinking to prepare a new FAQ version on the issue + a feature
request to Bugzilla. While making all data together, it remained me
another important oops of the current rendering model implemented in
major browsers (IE and FF at least):
1) window.onload handler call (a.k.a. body onload="...)
This call is being made at the moment then the DOM Tree of the
document is fully prepared so one can use DOM methods to any element
on the page. UA treats it as "the last chance" to make page
modifications before the initial display. As the result it *does not*
render the page until after load handler returns. If someone starts a
lengthly process on load, it leaves the user with system screen and
hourglasses for another N amount of time. So for such sutuation I
always use a "relay call" for onload instead of direct calls:
instead of:
window.onload = init;
function init() {
// lengthly process
}
do like this:
window.onload = relay;
function relay() {
window.setTimeout('init(args)',100);
}
// giving hard break so user will see something
// as soon as possible
function init() {
// lengthly process
}
Again: it is not a requirement of some "proper style" or anything, it
is a workaround for a particular situation with an extra lengthly
onload processing.
To see the usability difference, try this sample first (loop length up
to your processor speed, adjust if needed).
Not replace the relay call to direct call:
//window.onload = relay;
window.onload = init;
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
for (var i=0; i<100000; i++) {
new Date;
}
$('out').innerHTML = arguments[0] || 'New content';
}
function relay() {
window.setTimeout('init("Page content")',100);
}
function $(id) {
// Cornford special :-)
return document.getElementById(id);
}
window.onload = relay;
</script>
</head>
<body>
<p id="out">Default content</p>
</body>
</html>
VK
> Not replace the relay call to direct call:
> //window.onload = relay;
> window.onload = init;
"Now replace" of course
Randy Webb
> On Nov 25, 12:34 am, VK <schools_r...@yahoo.com> wrote:
>> P.S. What also amazes me is why all IE competitors keep neglecting
>> this problem? A heavy weight of bad habits?
>
> I am thinking to prepare a new FAQ version on the issue + a feature
> request to Bugzilla. While making all data together, it remained me
> another important oops of the current rendering model implemented in
> major browsers (IE and FF at least):
Coming from you, that is hilarious.
Leaves me wondering what village is short-handed though.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK
> VK said the following on 11/25/2007 10:03 AM:
>
> > On Nov 25, 12:34 am, VK <schools_r...@yahoo.com> wrote:
> >> P.S. What also amazes me is why all IE competitors keep neglecting
> >> this problem? A heavy weight of bad habits?
>
> > I am thinking to prepare a new FAQ version on the issue + a feature
> > request to Bugzilla. While making all data together, it remained me
> > another important oops of the current rendering model implemented in
> > major browsers (IE and FF at least):
>
> Coming from you, that is hilarious.
Randy, may I send you (gently but insistently) to the hell with such
useless comments? The code to demonstrate the issue is here,
workaround is here.
If you think that this onload processing issue is not an issue, then
state it.
If the code to demonstrate the issue do not demonstrate the issue on
your browser then take some more widely used browser, say recent IE or
FF.
If you have a better and more simple workaround then please disclose
it.
What is "hilarious" or not is a personal opinion of each side. What is
important to the Web development community and what they don't give
sh** about in 99% of cases is a rather well measurable trend.
VK
> > Coming from you, that is hilarious.
>
> Randy, may I send you (gently but insistently) to the hell with such
> useless comments?
Actually having read over your post I don't see a reason for such
excitement as demonstrated. Four years of intensive training I
guess :-) : someone is answering to a VK proposal - so some nasty to
answer by VK, no need to read through. :-)
Pavlov dog effect...
Randy Webb
Four years tends to do that to a person.
As for the "problem", there is a simple solution to the problem. There
is a bigger question to answer, and that is the issue of display
problems whether it is onload or not. You are proposing a very specific
solution to a very specific problem when the answer needs to be generic:
"Why doesn't my page update during a lengthy process?"
VK
> As for the "problem", there is a simple solution to the problem. There
> is a bigger question to answer, and that is the issue of display
> problems whether it is onload or not. You are proposing a very specific
> solution to a very specific problem when the answer needs to be generic:
OT a bit from my side - but not completely:
> "Why doesn't my page update during a lengthy process?"
Or should I go from another side and call it something like "I'm using
the hard break rendering bug workaround in my constructor/method call
and [this] looses its owner, what a hey?" :-)
The incontinence of [this] in the current language model and the
severely outdated rendering model in the current UAs are really one
problem despite these are two physically completely unrelated
problems.
By saying "here is the screen refresh problem, be aware, here is the
hard break workaround": by saying that one necessarily has to say what
to do to prevent [this] pointer lost on context exit, because it is
not 1998 and OOP rulez in each code.
By saying "so do not leave the context then": by saying that one
necessarily has to say what to do to prevent the screen refresh
problem and so on.
One may thing - often properly - a lot of bad things about ajaxoids,
but really AJAX was what has put this buggy-combo to the faces of
developers and UA producers. As the result many things became widely
used and often essential - from what was for years just abstract mind
games of a narrow group of people. Closure states, Cornford-Crockford
scope management variants - are now in the "public knowledge" and use
mainly - but not exclusively - because of AJAX and because of some
native environment limitations no one would bother before that,
except maybe selected readers of sources like:
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/
793cd655ad56fe91>
<http://www.crockford.com/javascript/private.html>
<http://www.litotes.demon.co.uk/js_info/private_static.html>
So from one end AJAX did to these constructs the same thing as
computers did to Boolean logic or physics did to some math models.
From the other end JavaScript programmers did their part of path in
full and now the "we don't care" position of UAs producers trigs more
of well-explainable irritation than surprise as it was earlier.
VK
or higher) without leaving the execution contect.
Initially posted by
Daniel LaLiberte, Brent Boyer, Martin Honnen, mercury rising
at
http://www.faqts.com/knowledge_base/view.phtml/aid/1602/javascript.forum.3006.9/a-fun-one-for-a.html
As I did not use IE's window.showModalDialog method too much, I cannot
tell is any security restrictions in newer versions will apply thus if
it can be used in the standard security environment. Any feedback on
that would be highly appreciated. Besides that and AFAICT it works
great and it does what mpsj's OP asked for.
It doesn't help too much on a wide run of course.
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function relay() {
window.setTimeout('init()',100);
}
function init() {
document.getElementById('elm').style.visibility = 'visible';
var dialogScript =
'window.setTimeout(' +
' function () { window.close(); }, ' + 10 + ');';
window.showModalDialog(
'javascript:document.writeln(' +
'"<script>' + dialogScript + '<' + '/script>")')
for (var i=0; i<100000; i++) {
new Date;
}
window.alert('End of loop');
}
</script>
</head>
<body onload="relay();">
<h1 id="elm" style="visibility:hidden">Page content</h1>
</body>
</html>
Randy Webb
> On Nov 25, 7:56 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> As for the "problem", there is a simple solution to the problem. There
>> is a bigger question to answer, and that is the issue of display
>> problems whether it is onload or not. You are proposing a very specific
>> solution to a very specific problem when the answer needs to be generic:
>
>
> OT a bit from my side - but not completely:
>
>> "Why doesn't my page update during a lengthy process?"
>
> Or should I go from another side and call it something like "I'm using
> the hard break rendering bug workaround in my constructor/method call
> and [this] looses its owner, what a hey?" :-)
I would ask what you are talking about but I am not sure you know.
VK
> VK said the following on 11/25/2007 12:58 PM:
>
> > On Nov 25, 7:56 pm, Randy Webb <HikksNotAtH...@aol.com> wrote:
> >> As for the "problem", there is a simple solution to the problem. There
> >> is a bigger question to answer, and that is the issue of display
> >> problems whether it is onload or not. You are proposing a very specific
> >> solution to a very specific problem when the answer needs to be generic:
>
> > OT a bit from my side - but not completely:
>
> >> "Why doesn't my page update during a lengthy process?"
>
> > Or should I go from another side and call it something like "I'm using
> > the hard break rendering bug workaround in my constructor/method call
> > and [this] looses its owner, what a hey?" :-)
>
> I would ask what you are talking about but I am not sure you know.
Sorry, Randy, but "sapienti sat est" from some point forward on... If
you feel that it is your duty/obligation as the FAQ Maintainer to
bring it back to the "normal English" then I'm just too buzy for that
at the moment, no offense.
Randy Webb
Somewhere on this planet there is a village hunting the resident idiot.
You want an FAQ Entry? Then write one. Just make sure that someone
besides you can understand what you are writing. And to date, nobody is
even sure that *you* understand what you write.
VK
> You want an FAQ Entry? Then write one. Just make sure that someone
> besides you can understand what you are writing. And to date, nobody is
> even sure that *you* understand what you write.
I am writing one. As soon as all ends are together I'll post the
initial proposal with <FAQ*NTRY> in it. The post you have responded
with a clarification demand was not a FAQ*NTRY proposal, that was some
side thoughts - marked as "OT a bit - but not completely". This way it
was merely a demand to explain what connection would be between the
current incontinence of [this] in JavaScript and hard breaks of the
execution flow over window.setTimeout.
Please respond to what you are responding to in the Usenet ;-) :-|
Randy Webb
> On Nov 27, 2:13 am, Randy Webb <HikksNotAtH...@aol.com> wrote:
>> You want an FAQ Entry? Then write one. Just make sure that someone
>> besides you can understand what you are writing. And to date, nobody is
>> even sure that *you* understand what you write.
>
> I am writing one.
That should be entertaining, to say the least :)
> As soon as all ends are together I'll post the initial proposal
> with <FAQ*NTRY> in it.
OK.
> The post you have responded with a clarification demand was not a
> FAQ*NTRY proposal, that was some side thoughts - marked as "OT a
> bit - but not completely". This way it was merely a demand to
> explain what connection would be between the current incontinence
> of [this] in JavaScript and hard breaks of the execution flow over
> window.setTimeout.
I won't repeat the last line I wrote that you quoted :)
> Please respond to what you are responding to in the Usenet ;-) :-|
Does that, in some way, imply that you think I tried to respond in any
other way?