Forcing Screen Updates

[Gene Wirchenko]

Dear JavaScripters:

The text that I am using has a tictactoe game that shows the use
of frames. What a bother to get it going, but I have.

An oddity is that the winning move is sometimes shown before the
alert about winning or losing, and sometimes, it is shown after. There
might be a race condition going on.

Is there any way to force screen updating to be complete before
displaying a modal?

I have Web-searched for an answer, but have not found anything
useful. I tried using setTimeout(), but that screwed up execution in
a way that I have not figured out.

This does have a practical use. In a data entry form, I might
want to correct some entries, tell the user to check the changes, and
confirm them. It is more difficult when the changes have not shown up
yet.

Sincerely,

Gene Wirchenko

 

[Richard Cornford]

Dear JavaScripters:

The text that I am using has a tictactoe game that shows
the use of frames. What a bother to get it going, but I have.

So would that be a 3 by 3 grid of frames into which some external
resource is loaded in order to show the zero, cross or blank state of
that position in the grid?

An oddity is that the winning move is sometimes shown before
the alert about winning or losing, and sometimes, it is shown
after. There might be a race condition going on.

Content loaded into frames is likely to be loaded asynchronously,
which might result in varying loading intervals (with varying
conditions such as network load) and varying parsing/rendering time
(with varying things such as CPU load). It may be that when the URL
for the individual frame is set sometimes the content arrives and is
processed/rendered quickly and at other times it takes longer to
arrive or render.

Is there any way to force screen updating to be complete
before displaying a modal?

That would be irrelevant if the issue is the timing of loading
external resources. It is certainly possible to arrange to be aware of
the completion of loading of external resources into frames. For
example, if the resource being loaded is an HTML page it could include
a script that is triggered - onload - that tells the containing
frameset page that it has arrived. Thus the containing frameset page
could keep track of which instructions it had issued to particular
frames to load external resources and which eternal resources had
announced their arrival, and so know when everything was in place for
it to do whatever next step it was intending.

I have Web-searched for an answer, but have not found
anything useful. I tried using setTimeout(), but that screwed
up execution in a way that I have not figured out.

This does have a practical use. In a data entry form,
I might want to correct some entries, tell the user to check
the changes, and confirm them. It is more difficult when the
changes have not shown up yet.

Usual form validation of that sort is carried out by client-side
script prior to submitting the form and so cancels the submit action
if corrections need making, (and/)or it is carried out by server side
scripts that return the form asserting which corrections need making.
In neither of those cases would require worrying about screen updates
as only the latter requires that the form be re-rendered and it
arrives to be re-rendered at exactly the same time as the information
that the user needs to correct something.

Richard.

 

[Tim Streater]

So would that be a 3 by 3 grid of frames into which some external
resource is loaded in order to show the zero, cross or blank state of
that position in the grid?

Yes, he means noughts-and-crosses.

 

[Gene Wirchenko]

So would that be a 3 by 3 grid of frames into which some external
resource is loaded in order to show the zero, cross or blank state of
that position in the grid?
Yes.


Content loaded into frames is likely to be loaded asynchronously,
which might result in varying loading intervals (with varying
conditions such as network load) and varying parsing/rendering time
(with varying things such as CPU load). It may be that when the URL
for the individual frame is set sometimes the content arrives and is
processed/rendered quickly and at other times it takes longer to
arrive or render.


That would be irrelevant if the issue is the timing of loading
external resources. It is certainly possible to arrange to be aware of
the completion of loading of external resources into frames. For
example, if the resource being loaded is an HTML page it could include
a script that is triggered - onload - that tells the containing
frameset page that it has arrived. Thus the containing frameset page

That sounded like a good idea. I decided to try it.
Unfortunately...

The pages that display X and O already have a form onload. They
are to the routines testing for loss/victory and include the alert()s
that are getting displayed before the page is.

onload firing means that the page has been loaded. I am now
wondering what "loaded" means? Can I count on the page being
displayed at this point? It appears not. How can I determine that
the page has been displayed?

could keep track of which instructions it had issued to particular
frames to load external resources and which eternal resources had
announced their arrival, and so know when everything was in place for
it to do whatever next step it was intending.

Is onload the correct event for determining this?


I did manage to kludge a solution. I really would like a
non-kludge solution.

The onload()s call ShowLoser() and ShowWinner() which have a
check and display an alert() if the game is over. I changed each to
if the check, then set a timeout and call a display function. The
display function simply has an alert().

I had to guess for an appropriate timeout value and started with
1000 ms. However, I tried cutting it down and got it down to 0!


Searching further, I have also now seen document.readyState. I
tried using that, but I can not seem to access values in ShowWinner()
unless they were declared in it, even a global! Something strange is
going on.

Usual form validation of that sort is carried out by client-side
script prior to submitting the form and so cancels the submit action
if corrections need making, (and/)or it is carried out by server side
scripts that return the form asserting which corrections need making.
In neither of those cases would require worrying about screen updates
as only the latter requires that the form be re-rendered and it
arrives to be re-rendered at exactly the same time as the information
that the user needs to correct something.

I would not be using it that way necessarily. If I catch an
error before submitting is selected by the user, I would still want to
make such corrections. I would want that the display is updated
before the alert() is display.

So, my queston stands.

Sincerely,

Gene Wirchenko

 

[Dr J R Stockton]

In comp.lang.javascript message <esstc7144g17f0vnpeodg4aiv3iid8357m@4ax.

The text that I am using has a tictactoe game that shows the use
of frames. What a bother to get it going, but I have.

An oddity is that the winning move is sometimes shown before the
alert about winning or losing, and sometimes, it is shown after. There
might be a race condition going on.

The situation is perfectly clear. You have a design or coding error in
your script. But it is hard to say what, or where, it is.

If you were to read the newsgroup FAQ, or ECMA 262 edition 5.1, or my
Web site, you might well do better. Try all three.

BTW, please do not assume that the generality of readers is familiar
with all Americanisms/Canadianisms. Use the international subset of
English, if you can.



If you want to be sure that the winning move is announced after it is
shown, let the code execution come to a natural end after the winning
move is shown. Immediately before that end, put

var Good, Result ;
// Good = ...
Result = Good ? 'win' : 'lose'
setTimeout("alert('" + Result + "')", 1000)

or, better

function Show() { alert(Result) }
var Good, Result ;
// Good = ...
Result = Good ? 'win' : 'lose'
setTimeout(Show, 1000)

The 1000 is for initial test; unless redrawing your game is unreasonably
complex, 10 should do. Therefore, consider 50 or 100.

There may, and probably should, be an explicit Method for redrawing the
screen, and optionally waiting until that is finished..