Puzzling frame prob

[oeyvind toft]

I have a frameset consisting of 3 frames: top, left and right.

In top frame: body onload calls a js init function to set (or resets) values
in textareas etc...in all frames.

In right frame: A large textarea for dynamicly updated text.

Problem: When clicking the browser 'update' this doesnt work:
myTextAreaOnTheRight = "";
UNLESS I put an alert(anything) before the statement.

So,

'myTextAreaOnTheRight = ""; '
doesnt work,

'alert(anything);
myTextAreaOnTheRight = ""; '

does.

(I`m using IE 6 on windows)

Any ideas ??


Oeyvind

 

[Richard Cornford]

I have a frameset consisting of 3 frames: top, left and right.

In top frame: body onload calls a js init function to set (or
resets) values in textareas etc...in all frames.

In right frame: A large textarea for dynamicly updated text.

Problem: When clicking the browser 'update' this doesnt work:
myTextAreaOnTheRight = "";
UNLESS I put an alert(anything) before the statement.

So,

'myTextAreaOnTheRight = ""; '
doesnt work,

'alert(anything);
myTextAreaOnTheRight = ""; '

does.

(I`m using IE 6 on windows)

Any ideas ??

Modifying the text contents of a textarea would usually involve
assigning a string to the - value - property of that textarea. You
appear to be assigning an empty sting to an identifier.

But the question you are actually asking is: "Why does some javascript
code that you cannot see behave in a particular way when interacting
with a series of HTML pages that your cannot see?". You can consider
yourself extremely lucky if you get a useful answer to that question.

Richard.

 

[oeyvind toft]

You are of course correct in pointing out the missing '.value'.
However, it is an error in my email, not in the code I`m talking about.

But the question you are actually asking is: "Why does some javascript
code that you cannot see behave in a particular way when interacting
with a series of HTML pages that your cannot see?". You can consider
yourself extremely lucky if you get a useful answer to that question.

Huh ??

My question was why an assignement works fine WITH an alert placed before
it,'
and doesnt work WITHOUT it.


Oeyvind

 

[Lee]

oeyvind toft said:

You are of course correct in pointing out the missing '.value'.
However, it is an error in my email, not in the code I`m talking about.


Huh ??

He's hinting that you need to show us the exact code that's
causing the problem. There are many possible reasons why
adding an alert() might work-around a design problem.

 

[oeyvind toft]

This works:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
alert("DEBUG");
textfield1.value = "";
}

This doesnt work:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
textfield1.value = "";
}

Happy now ??

'There are many possible reasons why
adding an alert() might work-around a design problem.'

Like what ??

I have to admit I`ve never ever before seen a variable assigment`s success
been
dependent on a meaningless alert placed before it.


Oeyvind

 

[Grant Wagner]

This works:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
alert("DEBUG");
textfield1.value = "";
}

This doesnt work:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
textfield1.value = "";
}

Happy now ??

Not quite. When does init() run? Are you absolutely positive that the content
of top.frames[2] has completely loaded before you call this function? If init()
runs as the window.onload event of the frame it is in, it is entirely possible
that the content of top.frames[2] is not completely loaded before it runs.

If the content of top.frames[2] is not loaded when you run this function, the
assignment to textfield1 should fail, and an alert() after the assignment
shouldn't resolve the problem, however there may be strange race conditions
within the JavaScript interpretor that allow this behaviour. Either that your
your real example places the alert() before the assignment to textfield1, in
which case it's a simple matter of the alert() providing enough of a delay to
allow top.frames[2] to load.

'There are many possible reasons why
adding an alert() might work-around a design problem.'

Like what ??

Like trying to access the content of another frame/window before it is
completely loaded. Adding alert() provides enough delay for the content of the
other frame/window to load completely.

<script type="text/javascript">
var w = window.open('somepage.html', 'someName');
// alert('DEBUG');
var textfield1 = w.document.getElementBy('ta');
textfield1.value = 'something';
</script>

The above code is almost certain to fail because somepage.html is unlikely to
be completely loaded by the time you attempt to make the assignment ot
textfield1. Uncomment the alert() however, and now the asynchronous loading of
the new window has time to finish before the script continues.

I have to admit I`ve never ever before seen a variable assigment`s success
been
dependent on a meaningless alert placed before it.

When dealing with cross-frame or multi-window scripting where things are
happening asynchronously, it is very easy to create race conditions where
things will work only with an alert(), or will work intermitantly.

The best way to deal with these situations is have each frame look after it's
own business. In other words, the frame containing the init() function
shouldn't be "reaching into" top.frames[2] to clear the value. Ideally,
top.frames[2] should clear it's own value, but if you have a reason to have it
happen from frames[0], then do something like:

-- in top.frames[2]

<body
onload="
if (top.frames[0].clearTextInput) {
top.frames[0].clearTextInput(document.getElementById('ta'));
}
"
-- in top.frames[0]

<script type="text/javascript">
function clearTextInput(txtInput) {
if (txtInput) {
txtInput.value = '';
}
}
</script>

This code guarantees that top.frames[2] is actually completely loaded before an
attempt is made to clear it's text area.

 

[oeyvind toft]

Hello grant

Thanks a lot for a great reply to my question.
Your thorough explanation made me a lot wiser when
it comes to the mix of frames and javascript...

Best regards,

Oeyvind

--
http://home.online.no/~oeyvtoft/ToftWeb/

This works:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
alert("DEBUG");
textfield1.value = "";
}

This doesnt work:

function init()
{
textfield1 = window.top.frames[2].document.getElementById("ta1");
textfield1.value = "";
}

Happy now ??

Not quite. When does init() run? Are you absolutely positive that the content
of top.frames[2] has completely loaded before you call this function? If init()
runs as the window.onload event of the frame it is in, it is entirely possible
that the content of top.frames[2] is not completely loaded before it runs.

If the content of top.frames[2] is not loaded when you run this function, the
assignment to textfield1 should fail, and an alert() after the assignment
shouldn't resolve the problem, however there may be strange race conditions
within the JavaScript interpretor that allow this behaviour. Either that your
your real example places the alert() before the assignment to textfield1, in
which case it's a simple matter of the alert() providing enough of a delay to
allow top.frames[2] to load.

'There are many possible reasons why
adding an alert() might work-around a design problem.'

Like what ??

Like trying to access the content of another frame/window before it is
completely loaded. Adding alert() provides enough delay for the content of the
other frame/window to load completely.

<script type="text/javascript">
var w = window.open('somepage.html', 'someName');
// alert('DEBUG');
var textfield1 = w.document.getElementBy('ta');
textfield1.value = 'something';
</script>

The above code is almost certain to fail because somepage.html is unlikely to
be completely loaded by the time you attempt to make the assignment ot
textfield1. Uncomment the alert() however, and now the asynchronous loading of
the new window has time to finish before the script continues.

I have to admit I`ve never ever before seen a variable assigment`s success
been
dependent on a meaningless alert placed before it.

When dealing with cross-frame or multi-window scripting where things are
happening asynchronously, it is very easy to create race conditions where
things will work only with an alert(), or will work intermitantly.

The best way to deal with these situations is have each frame look after it's
own business. In other words, the frame containing the init() function
shouldn't be "reaching into" top.frames[2] to clear the value. Ideally,
top.frames[2] should clear it's own value, but if you have a reason to have it
happen from frames[0], then do something like:

-- in top.frames[2]

<body
onload="
if (top.frames[0].clearTextInput) {
top.frames[0].clearTextInput(document.getElementById('ta'));
}
"
-- in top.frames[0]

<script type="text/javascript">
function clearTextInput(txtInput) {
if (txtInput) {
txtInput.value = '';
}
}
</script>

This code guarantees that top.frames[2] is actually completely loaded before an
attempt is made to clear it's text area.