AJAX POST problems on Firefox

Hi all,

I am having some odd problems with AJAX on Firefox (1.5). When I use
GET as the request method everything works ok, but when I do a POST the
remote function doesn't get the parameters I am passing to it.
Everything works fine on IE 6. Here's a couple samples of what I am
doing:

// using GET
url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'

ajaxRequest.onreadystatechange = callback;
ajaxRequest.open('GET', url, true);
ajaxRequest.send(null);

// using POST
url = 'http://www.myserver.com/cgi-bin/funct'
request = 'key1=value1&key2=value2'

ajaxRequest.onreadystatechange = callback;
ajaxRequest.open('POST', url, true);
ajaxRequest.send(request);

Do you guys see a problem?

Thanks,
Danny

re: AJAX POST problems on Firefox

Danny wrote:
[color=blue]
> I am having some odd problems with AJAX on Firefox (1.5). When I use
> GET as the request method everything works ok, but when I do a POST the
> remote function doesn't get the parameters I am passing to it.
> Everything works fine on IE 6. Here's a couple samples of what I am
> doing:
>
> // using GET
> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'[/color]

Declare all your variables using the `var' keyword always. And almost all
statements, including simple assignments, should be delimited by a trailing
semicolon in order to avoid side effects with automatic semicolon insertion
by the script engine.
[color=blue]
> ajaxRequest.onreadystatechange = callback;
> ajaxRequest.open('GET', url, true);[/color]

open() clears all event listeners with the XMLHttpRequest XUL object
implemented in Gecko-based browsers; probably this is also what the
original IXMLHTTPRequest interface does. Reverse the order of
those two statements.
[color=blue]
> ajaxRequest.send(null);
>
> // using POST
> url = 'http://www.myserver.com/cgi-bin/funct'
> request = 'key1=value1&key2=value2'
>
> ajaxRequest.onreadystatechange = callback;
> ajaxRequest.open('POST', url, true);[/color]

Same here.
[color=blue]
> ajaxRequest.send(request);
>
> Do you guys see a problem?[/color]

Yes, see above.


HTH

PointedEars

re: AJAX POST problems on Firefox

Danny wrote:[color=blue]
> Hi all,
>
> I am having some odd problems with AJAX on Firefox (1.5). When I use
> GET as the request method everything works ok, but when I do a POST the
> remote function doesn't get the parameters I am passing to it.
> Everything works fine on IE 6. Here's a couple samples of what I am
> doing:
>
> // using GET
> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'
>
> ajaxRequest.onreadystatechange = callback;
> ajaxRequest.open('GET', url, true);
> ajaxRequest.send(null);
>
> // using POST
> url = 'http://www.myserver.com/cgi-bin/funct'
> request = 'key1=value1&key2=value2'
>
> ajaxRequest.onreadystatechange = callback;
> ajaxRequest.open('POST', url, true);
> ajaxRequest.send(request);
>
> Do you guys see a problem?[/color]

To POST data you have to set the request header to
'application/x-www-form-urlencoded'
ajaxRequest.setRequestHeader('Content-type',
'application/x-www-form-urlencoded');

Be aware that some older implementations of Safari and Opera are bad
with setRequestHeader, so there you are limited by GET only. Not really
practically important (screw on them and let them finally update). Just
let you know that POST may fail for some rare visitors.

re: AJAX POST problems on Firefox

Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:[color=blue]
> Danny wrote:
>[color=green]
>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>> GET as the request method everything works ok, but when I do a POST the
>> remote function doesn't get the parameters I am passing to it.
>> Everything works fine on IE 6. Here's a couple samples of what I am
>> doing:
>>
>> // using GET
>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'[/color]
>
> Declare all your variables using the `var' keyword always.[/color]

No. Declare all your variables using the 'var' keyword *unless* you
understand the ramifications of not doing so. In the global scope, there
is no difference in the following two script blocks:

<script type="text/javascript">
myVariable = 'This is a global variable'
</script>

<script type="text/javascript">
var myVariable = 'This is a global variable'
</script>

Note: There are no trailing semi-colons. I very seldom add them in my
own code. I usually add them to Usenet code so I don't have to listen to
arguments such as this one about adding them. The script engine will add
them where they should be and won't add them where they shouldn't be.
[color=blue]
> And almost all statements, including simple assignments, should be delimited
> by a trailing semicolon in order to avoid side effects with automatic semicolon
> insertion by the script engine.[/color]

Unless you know where to and where not to put them, you are safer *not*
putting them in. There was a post just yesterday with a for statement
with a trailing semicolon that changed the meaning of the code.

for (var i=0;i<someArray.length;i++);

Or close to it. And that trailing semi-colon changed the meaning of the
code.

The last time I corrected you about this I asked for an example of code
where the lack of a trailing semi-colon *breaks* the code and adding it
back caused the error to cease.

function myFunction(){;

Syntax Error!!!

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: AJAX POST problems on Firefox

Randy Webb wrote:
[color=blue]
> Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:[color=green]
>> Danny wrote:[color=darkred]
>>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>>> GET as the request method everything works ok, but when I do a POST the
>>> remote function doesn't get the parameters I am passing to it.
>>> Everything works fine on IE 6. Here's a couple samples of what I am
>>> doing:
>>>
>>> // using GET
>>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'[/color]
>>
>> Declare all your variables using the `var' keyword always.[/color]
>
> No. Declare all your variables using the 'var' keyword *unless* you
> understand the ramifications of not doing so. In the global scope, there
> is no difference in the following two script blocks:
>
> <script type="text/javascript">
> myVariable = 'This is a global variable'
> </script>[/color]

Wrong. It has been proven before already that there can be an object in
the scope chain, before the global object, that is a host object. This
is the case in JScript as used in IE: if there is an HTML element with
name or ID of `myVariable' and `myVariable' has not been declared before,
this assignment results in an error everywhere in the code because this
host object implements the simple assignment operation differently than
specified in ECMAScript Edition 3 (which is nevertheless ECMAScript
compliant behavior.) Declaring this identifier as a variable identifier
avoids this runtime error because the scope chain is not used (global
declaration) or used differently (local declaration) then.

Therefore, variables should be declared _always_ (or they may be no
variables at all.)
[color=blue][color=green]
>> And almost all statements, including simple assignments, should be
>> delimited by a trailing semicolon in order to avoid side effects with
>> automatic semicolon insertion by the script engine.[/color]
>
> Unless you know where to and where not to put them, you are safer not
> putting them in.[/color]

Wrong.
[color=blue]
> There was a post just yesterday with a for statement
> with a trailing semicolon that changed the meaning of the code.
>
> for (var i=0;i<someArray.length;i++);[/color]

Which part of "almost" is unclear to you?


PointedEars

re: AJAX POST problems on Firefox

Randy Webb wrote:
[color=blue]
> Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:[color=green]
>> Danny wrote:[color=darkred]
>>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>>> GET as the request method everything works ok, but when I do a POST the
>>> remote function doesn't get the parameters I am passing to it.
>>> Everything works fine on IE 6. Here's a couple samples of what I am
>>> doing:
>>>
>>> // using GET
>>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'[/color]
>>
>> Declare all your variables using the `var' keyword always.[/color]
>
> No. Declare all your variables using the 'var' keyword *unless* you
> understand the ramifications of not doing so. In the global scope, there
> is no difference in the following two script blocks:
>
> <script type="text/javascript">
> myVariable = 'This is a global variable'
> </script>[/color]

Wrong. It has been proven before already that there can be an object in
the scope chain, before the global object, that is a host object. This
is the case in JScript as used in IE: if there is an HTML element with
name or ID of `myVariable' and `myVariable' has not been declared before,
this assignment results in an error everywhere in the code because this
host object implements the simple assignment operation differently than
specified in ECMAScript Edition 3 (which is nevertheless ECMAScript
compliant behavior.) Declaring this identifier as a variable identifier
avoids this runtime error because the scope chain is not used then for
the initialization.

Therefore, variables should be declared _always_ (or they may be no
variables at all.)
[color=blue][color=green]
>> And almost all statements, including simple assignments, should be
>> delimited by a trailing semicolon in order to avoid side effects with
>> automatic semicolon insertion by the script engine.[/color]
>
> Unless you know where to and where not to put them, you are safer not
> putting them in.[/color]

Wrong.
[color=blue]
> There was a post just yesterday with a for statement
> with a trailing semicolon that changed the meaning of the code.
>
> for (var i=0;i<someArray.length;i++);[/color]

Which part of "almost" is unclear to you?


PointedEars

re: AJAX POST problems on Firefox

Thomas 'PointedEars' Lahn said the following on 2/3/2006 8:50 AM:[color=blue]
> Randy Webb wrote:
>[color=green]
>> Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:[color=darkred]
>>> Danny wrote:
>>>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>>>> GET as the request method everything works ok, but when I do a POST the
>>>> remote function doesn't get the parameters I am passing to it.
>>>> Everything works fine on IE 6. Here's a couple samples of what I am
>>>> doing:
>>>>
>>>> // using GET
>>>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'
>>> Declare all your variables using the `var' keyword always.[/color]
>> No. Declare all your variables using the 'var' keyword *unless* you
>> understand the ramifications of not doing so. In the global scope, there
>> is no difference in the following two script blocks:
>>
>> <script type="text/javascript">
>> myVariable = 'This is a global variable'
>> </script>[/color]
>
> Wrong.[/color]

Wrong Thomas.

Let me quote what you ignored ok? Make sure you read it properly this time:

IN THE GLOBAL SCOPE.

Get it now? In the GLOBAL scope they are equivalent.
[color=blue]
> It has been proven before already that there can be an object in
> the scope chain, before the global object, that is a host object.[/color]

Irrelevant to what I said.
[color=blue]
> This is the case in JScript as used in IE: if there is an HTML element with
> name or ID of `myVariable' and `myVariable' has not been declared before,
> this assignment results in an error everywhere in the code because this
> host object implements the simple assignment operation differently than
> specified in ECMAScript Edition 3 (which is nevertheless ECMAScript
> compliant behavior.)[/color]

Yoohoo. Read what I wrote Thomas : "Unless you understand the
ramifications of not doing so".

Sidenote: I don't give a crap what ECMA says. I care what the browsers do.
[color=blue]
> Declaring this identifier as a variable identifier avoids this runtime
> error because the scope chain is not used (global declaration) or used
> differently (local declaration) then.[/color]

And if you are stupid enough to name your variables the same as your
ID's, then you deserve what you get. Using IE as a defense is no defense
at all.

And, please oh please name just one browser on the Web where the above
script won't create a Global Variable. Just one.

But, just in case you missed it again, let me repeat what I said one
more time:

In the GLOBAL SCOPE, there is no difference in the two script blocks.
Declare all your variables using the 'var' keyword *unless* you
understand the ramifications of not doing so.

Do you fail to understand what I wrote? You must.
[color=blue]
> Therefore, variables should be declared _always_ (or they may be no
> variables at all.)[/color]

Again, you didn't understand what I wrote. Try it again.

[color=blue][color=green][color=darkred]
>>> And almost all statements, including simple assignments, should be
>>> delimited by a trailing semicolon in order to avoid side effects with
>>> automatic semicolon insertion by the script engine.[/color]
>> Unless you know where to and where not to put them, you are safer not
>> putting them in.[/color]
>
> Wrong.[/color]

Once again, you are wrong Thomas.
[color=blue][color=green]
>> There was a post just yesterday with a for statement
>> with a trailing semicolon that changed the meaning of the code.
>>
>> for (var i=0;i<someArray.length;i++);[/color]
>
> Which part of "almost" is unclear to you?[/color]

Let me repeat for you, again, what I wrote and I will endeavor to
explain it to you since you either ignored it or didn't comprehend it:

<quote>
Unless you know where to and where not to put them, you are safer not
putting them in.
</quote>

Now, you get an example that maybe will shed some light on what you are
missing.

<script type="text/javascript">
myNonVarDeclaredVariable = 0
for (var i=0;i<100;i++)
{
myNonVarDeclaredVariable++
}
alert(myNonVarDeclaredVariable)
</script>

Thats perfectly valid Script. It will do what it was designed to do.
Increment a variable. It does that. Now, someone comes along and reads
PointedEars saying "End your statements with ;" and they add semi-colons
to the ends of all the lines and get this:

<script type="text/javascript">
myNonVarDeclaredVariable = 0;
for (var i=0;i<100;i++);
{;
myNonVarDeclaredVariable++;
};
alert(myNonVarDeclaredVariable);
</script>

Now, by not understanding when to, and not to, add semi-colons the
unknowing just changed what the code does and introduced syntax errors.

So, "Unless you know where to and where not to put them, you are safer
not putting them in".

The JS Engine will parse the script block and insert them where they
belong and will not insert them where they do not belong.

When writing, it is better to be clear and concise. Your statement left
a lot of ambiguity, mine did not. Learn the difference.

Then, take your corrections like a man.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: AJAX POST problems on Firefox

Randy Webb wrote:

[Readded previously snipped code]
[color=blue]
> Thomas 'PointedEars' Lahn said the following on 2/3/2006 8:50 AM:[color=green]
>> Randy Webb wrote:[color=darkred]
>>> Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:
>>>> Danny wrote:
>>>>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>>>>> GET as the request method everything works ok, but when I do a POST
>>>>> the remote function doesn't get the parameters I am passing to it.
>>>>> Everything works fine on IE 6. Here's a couple samples of what I am
>>>>> doing:
>>>>>
>>>>> // using GET
>>>>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'
>>>> Declare all your variables using the `var' keyword always.
>>> No. Declare all your variables using the 'var' keyword *unless* you
>>> understand the ramifications of not doing so. In the global scope, there
>>> is no difference in the following two script blocks:
>>>
>>> <script type="text/javascript">
>>> myVariable = 'This is a global variable'
>>> </script>
>>>
>>> <script type="text/javascript">
>>> var myVariable = 'This is a global variable'
>>> </script>[/color]
>>
>> Wrong.[/color]
>
> Wrong Thomas.[/color]

No, I am correct.
[color=blue]
> Let me quote what you ignored ok? Make sure you read it properly this
> time:
>
> IN THE GLOBAL SCOPE.
>
> Get it now? In the GLOBAL scope they are equivalent.[/color]

No, they are _not_, in /any/ scope. In the first case the scope chain is
used; in the second case it is not.
[color=blue][color=green]
>> It has been proven before already that there can be an object in
>> the scope chain, before the global object, that is a host object.[/color]
>
> Irrelevant to what I said.[/color]

It is very relevant to what you said. You can seldom know, with Closed
Source you can never know, the inner workings of the implementation used,
including the scope chain. It is error-prone and eventually incompetent
to ignore that.
[color=blue][color=green]
>> This is the case in JScript as used in IE: if there is an HTML element
>> with name or ID of `myVariable' and `myVariable' has not been declared
>> before, this assignment results in an error everywhere in the code
>> because this host object implements the simple assignment operation
>> differently than specified in ECMAScript Edition 3 (which is nevertheless
>> ECMAScript compliant behavior.)[/color]
>
> Yoohoo. Read what I wrote Thomas : "Unless you understand the
> ramifications of not doing so".[/color]

You yourself did not understand the ramifications of doing so (yet?).
[color=blue]
> Sidenote: I don't give a crap what ECMA says.[/color]

Then you are a fool because you are dealing with conforming implementations
of ECMAScript (ECMA-262, ISO/IEC 16262). Not only because I (and a
considerable number of other participants of this newsgroup) say so, but
because the creators of the respective script engines themselves say so.
[color=blue]
> I care what the browsers do.[/color]

Then read the previous discussion on the subject as I already suggested. It
contains an example that _breaks_ in IE if the identifier is not a declared
variable. It does _not_ break if it is.

BTW: You replied to a posting canceled (on Google Groups) and superseded
with news:2045801.nuuUZg5zpb@PointedEars.de already.


PointedEars

re: AJAX POST problems on Firefox

Thomas 'PointedEars' Lahn said the following on 2/3/2006 11:54 AM:[color=blue]
> Randy Webb wrote:
>
> [Readded previously snipped code]
>[color=green]
>> Thomas 'PointedEars' Lahn said the following on 2/3/2006 8:50 AM:[color=darkred]
>>> Randy Webb wrote:
>>>> Thomas 'PointedEars' Lahn said the following on 2/2/2006 5:14 PM:
>>>>> Danny wrote:
>>>>>> I am having some odd problems with AJAX on Firefox (1.5). When I use
>>>>>> GET as the request method everything works ok, but when I do a POST
>>>>>> the remote function doesn't get the parameters I am passing to it.
>>>>>> Everything works fine on IE 6. Here's a couple samples of what I am
>>>>>> doing:
>>>>>>
>>>>>> // using GET
>>>>>> url = 'http://www.myserver.com/cgi-bin/funct?key1=value1&key2=value2'
>>>>> Declare all your variables using the `var' keyword always.
>>>> No. Declare all your variables using the 'var' keyword *unless* you
>>>> understand the ramifications of not doing so. In the global scope, there
>>>> is no difference in the following two script blocks:
>>>>
>>>> <script type="text/javascript">
>>>> myVariable = 'This is a global variable'
>>>> </script>
>>>>
>>>> <script type="text/javascript">
>>>> var myVariable = 'This is a global variable'
>>>> </script>
>>> Wrong.[/color]
>> Wrong Thomas.[/color]
>
> No, I am correct.[/color]

That is your opinion, and you are entitled to it. Your opinion is based
on ignoring *all* of what I wrote. But, that is your choice. Should
people use the var keyword? Sure. Can they do without it? Yes, but, only
if they understand the ramifications of not using it. The ramifications
part is what you are ignoring.

[color=blue]
>[color=green]
>> Let me quote what you ignored ok? Make sure you read it properly this
>> time:
>>
>> IN THE GLOBAL SCOPE.
>>
>> Get it now? In the GLOBAL scope they are equivalent.[/color]
>
> No, they are _not_, in /any/ scope. In the first case the scope chain is
> used; in the second case it is not.[/color]

You still didn't get it. If both of those script blocks are executed in
the global scope then they are both global variables. Show me some code
that shows otherwise though.
[color=blue][color=green][color=darkred]
>>> It has been proven before already that there can be an object in
>>> the scope chain, before the global object, that is a host object.[/color]
>> Irrelevant to what I said.[/color]
>
> It is very relevant to what you said.[/color]

No it's not. If you understand the ramifications, and the behavior you
get is what you are after, then you can do what you want. If you don't
understand, then take the safe path and use the var keyword.
[color=blue]
> You can seldom know, with Closed
> Source you can never know, the inner workings of the implementation used,
> including the scope chain. It is error-prone and eventually incompetent
> to ignore that.[/color]

Again, only if you don't understand the ramifications of not using the
var keyword.

If I repeat that enough, will you finally get it?

[color=blue][color=green][color=darkred]
>>> This is the case in JScript as used in IE: if there is an HTML element
>>> with name or ID of `myVariable' and `myVariable' has not been declared
>>> before, this assignment results in an error everywhere in the code
>>> because this host object implements the simple assignment operation
>>> differently than specified in ECMAScript Edition 3 (which is nevertheless
>>> ECMAScript compliant behavior.)[/color]
>> Yoohoo. Read what I wrote Thomas : "Unless you understand the
>> ramifications of not doing so".[/color]
>
> You yourself did not understand the ramifications of doing so (yet?).[/color]

You underestimate my understanding. I am well aware of what the
ramifications are.
[color=blue][color=green]
>> Sidenote: I don't give a crap what ECMA says.[/color]
>
> Then you are a fool because you are dealing with conforming implementations
> of ECMAScript (ECMA-262, ISO/IEC 16262).[/color]

I am a fool for not caring what a document says but rather I worry more
about what the browsers do? I can write cross-browser scripts and never
even know what ECMA says. You can not write cross-browser scripts based
solely on knowing what ECMA says. You *must* know the browser behavior.
And given a choice between MSDN and the Gecko docs versus ECMA's
documentation, you can have ECMA.

And to prove that point, it only takes using toFixed in IE and you will
soon find out that it's more important to know what the browser is going
to do than what ECMA says it should do because IE5.0 in its default
install configuration will fail with toFixed because its buggy.
[color=blue]
> Not only because I (and a considerable number of other participants of
> this newsgroup) say so, but because the creators of the respective script
> engines themselves say so.[/color]

ECMA is an attempt to standardize what was already in place. Not the
other way around.

Theory: ECMA should be all you need to know.
Reality: ECMA doesn't mean a hill of beans.

If it did, then the language would be ECMAScript and not J(ava)script.

[color=blue][color=green]
>> I care what the browsers do.[/color]
>
> Then read the previous discussion on the subject as I already suggested. It
> contains an example that _breaks_ in IE if the identifier is not a declared
> variable. It does _not_ break if it is.[/color]

And I already said that if you are stupid enough to fall into that trap
then you deserve what you get. That is one of the ramifications I was
referring to that you keep ignoring.

But, which is it? Are you going to stand behind ECMA or the browser's
behavior? You can't have it both ways.
[color=blue]
> BTW: You replied to a posting canceled (on Google Groups) and superseded
> with news:2045801.nuuUZg5zpb@PointedEars.de already.[/color]

BTW: It was not cancelled or I wouldn't have seen it. And you are
assuming that just because you went to Google and asked for the message
to be cancelled that it did indeed get cancelled - it didn't.

But, since you mention the double post, you should fix your newsreader -
it double posts quite a bit.

What? No more about the semi-colons?
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

re: AJAX POST problems on Firefox

JRS: In article <w5adna9YgOA5nXvenZ2dnUVZ_t2dnZ2d@comcast.com>, dated
Sun, 5 Feb 2006 08:48:24 remote, seen in news:comp.lang.javascript,
Randy Webb <HikksNotAtHome@aol.com> posted :[color=blue]
>
>But, since you mention the double post, you should fix your newsreader -
>it double posts quite a bit.[/color]

That may be because he uses supersedes, presumably in an endeavour to
cover up careless hasty posting.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.

re: AJAX POST problems on Firefox

Dr John Stockton said the following on 2/6/2006 10:16 AM:[color=blue]
> JRS: In article <w5adna9YgOA5nXvenZ2dnUVZ_t2dnZ2d@comcast.com>, dated
> Sun, 5 Feb 2006 08:48:24 remote, seen in news:comp.lang.javascript,
> Randy Webb <HikksNotAtHome@aol.com> posted :[color=green]
>> But, since you mention the double post, you should fix your newsreader -
>> it double posts quite a bit.[/color]
>
> That may be because he uses supersedes, presumably in an endeavour to
> cover up careless hasty posting.[/color]

Don't let him know that not all News Servers honor the superseded
Header. If you do, he will go on for weeks about RFC's and such and end
up saying it is my fault I saw his double posts. <g>

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/