Showing a 'Waiting ...' Message

D

Dr J R Stockton

In comp.lang.javascript message <n70le79a1ccst08497ugge084fo9f5qctq@4ax.
Now, why do I not find this sort of stuff written up in any books
or Website that I read? I only find out because of running into the
problems. Not the most efficient way of going about things, is it?

As far as I recall we know, you are relying on one very old book, which
you have not named.


Consider first a plain HTML page. It is a nested structure of elements,
with an element represented by <tag> ... </tag> - though in some cases
(like <p>) the </tag> is not necessary in the HTML, as the parser can
see where it must be; and in other cases (like <hr>), where there is no
.... part, there may be no closing tag.

That nested-box structure is equivalent to a tree structure, which is
easier to think about. As time permits, that tree will be rendered on
the screen. AIUI, script execution can interrupt rendering, but
rendering cannot interrupt script.

One particular box is the <script> box.

As the page source is read from wherever, with included files treated as
if in the source, it is parsed and the DOM tree is built. Scripts found
are immediately executed. Some pieces of script merely do internal
operations like arithmetic or string-twiddling. Function statements
merely define functions, ready to be called. Statements document.write
and document.writeln add to the DOM tree. Statements can, by using
getElementById, walking the DOM tree, or using quasi-arrays such as
forms, alter the DOM tree; but they can only alter what already exists.

When the end of the source is reached, no further code is executed,
except as a result of an event. Events are chiefly the result of mouse-
clicks, or of keyboard actions, or are caused by setTimeout expiring or
setInterval ticking (there may be others).

In event code, any unqualified document.write and document.writeln
writes to the current window, essentially uprooting the old DOM tree and
beginning a new DOM tree (it is possible that scripts or include files
may survive in some or all browsers).

NOTE : I/O elements within a Form [commonly] have a property 'form'
which is effectively a pointer to the form. There is also a property
'this'.

Consider as an illustration an on/off button in a form
<input type=button value=1 onclick="Cluck(this)">
with already constructed
function Cluck(Me) {
(Me.value ^= 1) ? StopJob(Me.form) : StartJob(Me.form) }

Pressing the button toggles its value (I'm assuming buttons labelled
with 0 & 1 are known in BC) and starts or stops the Job (possibly in the
other order); and the job code has access to the value of Me.form which
it can use to read/write the Form.

The code has been tested.

I don't doubt your statement that there is nothing like that on the Web
that you can find; but you should not make such a statement again.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,767
Messages
2,569,570
Members
45,045
Latest member
DRCM

Latest Threads

Top