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:
myTextAreaOnThe Right = "";
UNLESS I put an alert(anything) before the statement.

So,

'myTextAreaOnTh eRight = ""; '
doesnt work,

'alert(anything );
myTextAreaOnThe Right = ""; '

does.

(I`m using IE 6 on windows)

Any ideas ??


Oeyvind


--

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

[Richard Cornford]

Re: Puzzling frame prob

oeyvind toft wrote:[color=blue]
> 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:
> myTextAreaOnThe Right = "";
> UNLESS I put an alert(anything) before the statement.
>
> So,
>
> 'myTextAreaOnTh eRight = ""; '
> doesnt work,
>
> 'alert(anything );
> myTextAreaOnThe Right = ""; '
>
> does.
>
> (I`m using IE 6 on windows)
>
> Any ideas ??[/color]

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]

Re: Puzzling frame prob


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.
[color=blue]
> 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.[/color]

Huh ??

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


Oeyvind


--

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

"Richard Cornford" <Richard@litote s.demon.co.uk> skrev i melding
news:ch9p2e$pj2 $1$8302bc10@new s.demon.co.uk.. .[color=blue]
> oeyvind toft wrote:[color=green]
> > 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:
> > myTextAreaOnThe Right = "";
> > UNLESS I put an alert(anything) before the statement.
> >
> > So,
> >
> > 'myTextAreaOnTh eRight = ""; '
> > doesnt work,
> >
> > 'alert(anything );
> > myTextAreaOnThe Right = ""; '
> >
> > does.
> >
> > (I`m using IE 6 on windows)
> >
> > Any ideas ??[/color]
>
> 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.
>
>[/color]

[Lee]

Re: Puzzling frame prob

oeyvind toft said:[color=blue]
>
>
>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.
>[color=green]
>> 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.[/color]
>
>Huh ??[/color]

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]

Re: Puzzling frame prob

This works:

function init()
{
textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
alert("DEBUG");
textfield1.valu e = "";
}

This doesnt work:

function init()
{
textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
textfield1.valu e = "";
}

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

--

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

"Lee" <REM0VElbspamtr ap@cox.net> skrev i melding
news:ch9s9b01fm d@drn.newsguy.c om...[color=blue]
> oeyvind toft said:[color=green]
> >
> >
> >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.
> >[color=darkred]
> >> 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.[/color]
> >
> >Huh ??[/color]
>
> 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.
>[/color]

[Grant Wagner]

Re: Puzzling frame prob

oeyvind toft wrote:
[color=blue]
> This works:
>
> function init()
> {
> textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
> alert("DEBUG");
> textfield1.valu e = "";
> }
>
> This doesnt work:
>
> function init()
> {
> textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
> textfield1.valu e = "";
> }
>
> Happy now ??[/color]

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.
[color=blue]
> 'There are many possible reasons why
> adding an alert() might work-around a design problem.'
>
> Like what ??[/color]

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('so mepage.html', 'someName');
// alert('DEBUG');
var textfield1 = w.document.getE lementBy('ta');
textfield1.valu e = '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.
[color=blue]
> I have to admit I`ve never ever before seen a variable assigment`s success
> been
> dependent on a meaningless alert placed before it.[/color]

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.getEl ementById('ta') );
}
"[color=blue]
>[/color]

-- 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.

--
Grant Wagner <gwagner@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[oeyvind toft]

Re: Puzzling frame prob

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/

"Grant Wagner" <gwagner@agrico reunited.com> skrev i melding
news:41389022.5 848D437@agricor eunited.com...[color=blue]
> oeyvind toft wrote:
>[color=green]
> > This works:
> >
> > function init()
> > {
> > textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
> > alert("DEBUG");
> > textfield1.valu e = "";
> > }
> >
> > This doesnt work:
> >
> > function init()
> > {
> > textfield1 = window.top.fram es[2].document.getEl ementById("ta1" );
> > textfield1.valu e = "";
> > }
> >
> > Happy now ??[/color]
>
> Not quite. When does init() run? Are you absolutely positive that the[/color]
content[color=blue]
> of top.frames[2] has completely loaded before you call this function? If[/color]
init()[color=blue]
> runs as the window.onload event of the frame it is in, it is entirely[/color]
possible[color=blue]
> 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,[/color]
the[color=blue]
> assignment to textfield1 should fail, and an alert() after the assignment
> shouldn't resolve the problem, however there may be strange race[/color]
conditions[color=blue]
> within the JavaScript interpretor that allow this behaviour. Either that[/color]
your[color=blue]
> your real example places the alert() before the assignment to textfield1,[/color]
in[color=blue]
> which case it's a simple matter of the alert() providing enough of a delay[/color]
to[color=blue]
> allow top.frames[2] to load.
>[color=green]
> > 'There are many possible reasons why
> > adding an alert() might work-around a design problem.'
> >
> > Like what ??[/color]
>
> Like trying to access the content of another frame/window before it is
> completely loaded. Adding alert() provides enough delay for the content of[/color]
the[color=blue]
> other frame/window to load completely.
>
> <script type="text/javascript">
> var w = window.open('so mepage.html', 'someName');
> // alert('DEBUG');
> var textfield1 = w.document.getE lementBy('ta');
> textfield1.valu e = 'something';
> </script>
>
> The above code is almost certain to fail because somepage.html is unlikely[/color]
to[color=blue]
> be completely loaded by the time you attempt to make the assignment ot
> textfield1. Uncomment the alert() however, and now the asynchronous[/color]
loading of[color=blue]
> the new window has time to finish before the script continues.
>[color=green]
> > I have to admit I`ve never ever before seen a variable assigment`s[/color][/color]
success[color=blue][color=green]
> > been
> > dependent on a meaningless alert placed before it.[/color]
>
> 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[/color]
it's[color=blue]
> 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[/color]
have it[color=blue]
> happen from frames[0], then do something like:
>
> -- in top.frames[2]
>
> <body
> onload="
> if (top.frames[0].clearTextInput ) {
> top.frames[0].clearTextInput (document.getEl ementById('ta') );
> }
> "[color=green]
> >[/color]
>
> -- 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[/color]
before an[color=blue]
> attempt is made to clear it's text area.
>
> --
> Grant Wagner <gwagner@agrico reunited.com>
> comp.lang.javas cript FAQ - http://jibbering.com/faq
>[/color]