What's wrong with the following code to capture the Browser type?

[Greener]

Hi, I need help badly. Can you do client-side programming instead of
server-side to capture the Browser type info? If this is the case,
what's wrong with the following?
<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)
{
var w = new ActiveXObject(" Word.Applicatio n");
if (w != null)
{
w.Visible = true;

w.Documents.Ope n(file);

}
}
else
{
document.write( ...)
}

}
</script>

but it doesn't work.
So I am wondering about what's wrong. Thanks for your advice.

Helena

[HikksNotAtHome]

In article <9c************ *************@p osting.google.c om>,
he********@yaho o.com (Greener) writes:

Hi, I need help badly. Can you do client-side programming instead of
server-side to capture the Browser type info?
You can do it, reliably, neither on the server nor in the browser. Why does it
matter what browser I am using?
If this is the case, what's wrong with the following?
The major problem is you are relying on an unreliable string to attempt to
determine the browser.


<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)

Not sure how to object test for ActiveX, never tried to. And there is probably
a browser besides IE that will pass the following, but I am not sure:

if (document.all && document.getEle mentById &! window.opera){
alert('You might be using IE')
}

Perhaps a VBScript script instead, which is IE only (as far as I know):

<script type="text/vbscript">
//Not a single clue what would go here
</script>

None of which relies on what browser I am using.

http://www.jibbering.com/faq/#FAQ4_26

And links therein, to http://www.xs4all.nl/~ppk/js/support.html
--
Randy

[Lee]

Greener said:

Hi, I need help badly. Can you do client-side programming instead of
server-side to capture the Browser type info? If this is the case,
what's wrong with the following?
<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)
{
var w = new ActiveXObject(" Word.Applicatio n");
if (w != null)
{
w.Visible = true;

w.Documents.Ope n(file);

}
}
else
{
document.write( ...)
}

}
</script>

but it doesn't work.
So I am wondering about what's wrong. Thanks for your advice.

It should have some sort of error handling code in case w == null,
but other than that, it works for me. What do you mean when you
say "it doesn't work". What does it do, instead of opening Word?

[Richard Cornford]

"HikksNotAtHome " <hi************ @aol.com> wrote in message
news:20******** *************** ****@mb-m11.aol.com...

In article <9c************ *************@p osting.google.c om>,
he********@yaho o.com (Greener) writes:

Hi, I need help badly. Can you do client-side programming
instead of server-side to capture the Browser type info?
You can do it, reliably, neither on the server nor in the
browser. Why does it matter what browser I am using?

I assume that was intended to start "you can not do it, . . . ".

If this is the case, what's wrong with the following?

The major problem is you are relying on an unreliable
string to attempt to determine the browser.

<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)

Not sure how to object test for ActiveX, never tried to.
And there is probably a browser besides IE that will pass
the following, but I am not sure:

Yes, Konqueror (so probably Safari), IceBrowser and Web Browser 2.0. In
fact I think that test probably only rules out Opera and Gecko browsers
as it seems to be common these days for non-IE browsers to be
implementing a document.all collection.
if (document.all && document.getEle mentById &! window.opera){
alert('You might be using IE')
}

<snip>

I would have thought that, since the desire is to call the ActiveXObject
constructor, the pertinent test would be for the existence of the
ActiveXObject constructor:-

if(window.Activ eXObject){
// new ActiveXObject can be called.
}
-or-
if(typeof ActiveXObject != 'undefined'){
// new ActiveXObject can be called.
}

Following the principal that you feature/object test as close to the
problem as possible.

However, with IceBrowser being an example of at least one browser that
has a fake ActiveXObject constructor it becomes very important to test
the object returned to ensure that it is an object. The OP's - if (w !=
null) - is a good start but it would also be worth checking that the
object has the methods and properties that the script wants to call (eg.
Documents.Open) in case the ActiveXObject constructor is a fake that
just returns a standard JavaScript object.

But then there are the ActiveX user preferences. My IE 6 will not allow
any scripting of ActiveX over the internet so even if it could be
determined by other means that the browser was IE 6 the script would
still not execute on it.

Just to add to the confusion, I recently read in a netscape.public .*
group of development work on ActiveX for windows Gecko browsers with a
new "GeckoActiveXOb ject" constructor. So maybe this script would not be
limited to just IE in the future. Though I got the impression that the
Gecko ActiveX support would be for custom ActiveX controls and not
Microsoft ones such a Word.Applicatio n.

Richard.

[HikksNotAtHome]

In article <bl************ *******@news.de mon.co.uk>, "Richard Cornford"
<Ri*****@litote s.demon.co.uk> writes:

You can do it, reliably, neither on the server nor in the
browser. Why does it matter what browser I am using?
I assume that was intended to start "you can not do it, . . . ".

I think I put too many negatives in there. You can do it, reliably, neither on
the server or in the browser:

You can't do it reliably.

Same thing. I got too verbose on myself :(

<--snip-->

I would have thought that, since the desire is to call the ActiveXObject
constructor, the pertinent test would be for the existence of the
ActiveXObjec t constructor:-

if(window.Acti veXObject){
// new ActiveXObject can be called.
}
-or-
if(typeof ActiveXObject != 'undefined'){
// new ActiveXObject can be called.
}

Thats what I was alluding to, but had no idea how to do it, never tried to :)
--
Randy

[Richard Cornford]

"HikksNotAtHome " <hi************ @aol.com> wrote in message
news:20******** *************** ****@mb-m11.aol.com...

You can do it, reliably, neither on the server nor in the
browser. Why does it matter what browser I am using?
I assume that was intended to start "you can not do it, ... ".

I think I put too many negatives in there. You can do it,
reliably, neither on the server or in the browser:

You can't do it reliably.

Same thing. I got too verbose on myself :(

<snip>

Its not as if I don't do that myself more often than I should.
(or do I? ;-)

Richard.

[Greener]

First of all, thanks to all for the assistances!

When I meant it didn't work, I saw on the left bottom corner right
above the toolbar, "Error on Page", after i click a button to do the
following function.
Lee <RE************ **@cox.net> wrote in message news:<bl******* *@drn.newsguy.c om>...

Greener said:

Hi, I need help badly. Can you do client-side programming instead of
server-side to capture the Browser type info? If this is the case,
what's wrong with the following?
<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)
{
var w = new ActiveXObject(" Word.Applicatio n");
if (w != null)
{
w.Visible = true;

w.Documents.Ope n(file);

}
}
else
{
document.write( ...)
}

}
</script>

but it doesn't work.
So I am wondering about what's wrong. Thanks for your advice.

It should have some sort of error handling code in case w == null,
but other than that, it works for me. What do you mean when you
say "it doesn't work". What does it do, instead of opening Word?

[Greener]

Thanks a lot. I tried to insert the following piece of code to my code
in several possible places: if(window.Activ eXObject){
// new ActiveXObject can be called.
}
<script language="JavaS cript">
function doWord(file)
{
if(window.Activ eXObject){
if (navigator.user Agent.indexOf(" MSIE")!=-1)
{
var w = new ActiveXObject(" Word.Applicatio n");
if (w != null)
{
w.Visible = true;

w.Documents.Ope n(file);

}
}
else
{
document.write( ...)
}
}
}
</script>
It still didn't work. Should I also try the other way you mentioned?
That is,

if(typeof ActiveXObject != 'undefined'){
// new ActiveXObject can be called.
}
What went wrong? How to make it work? Bear with me and sorry for my
ignorance.

"Richard Cornford" <Ri*****@litote s.demon.co.uk> wrote in message news:<bl******* ************@ne ws.demon.co.uk> ...

"HikksNotAtHome " <hi************ @aol.com> wrote in message
news:20******** *************** ****@mb-m11.aol.com...

In article <9c************ *************@p osting.google.c om>,
he********@yaho o.com (Greener) writes:

Hi, I need help badly. Can you do client-side programming
instead of server-side to capture the Browser type info?

You can do it, reliably, neither on the server nor in the
browser. Why does it matter what browser I am using?

I assume that was intended to start "you can not do it, . . . ".

If this is the case, what's wrong with the following?

The major problem is you are relying on an unreliable
string to attempt to determine the browser.

<script language="JavaS cript">
function doWord(file)
{

if (navigator.user Agent.indexOf(" MSIE")!=-1)

Not sure how to object test for ActiveX, never tried to.
And there is probably a browser besides IE that will pass
the following, but I am not sure:

Yes, Konqueror (so probably Safari), IceBrowser and Web Browser 2.0. In
fact I think that test probably only rules out Opera and Gecko browsers
as it seems to be common these days for non-IE browsers to be
implementing a document.all collection.

if (document.all && document.getEle mentById &! window.opera){
alert('You might be using IE')
}

<snip>

I would have thought that, since the desire is to call the ActiveXObject
constructor, the pertinent test would be for the existence of the
ActiveXObject constructor:-

if(window.Activ eXObject){
// new ActiveXObject can be called.
}
-or-
if(typeof ActiveXObject != 'undefined'){
// new ActiveXObject can be called.
}

Following the principal that you feature/object test as close to the
problem as possible.

However, with IceBrowser being an example of at least one browser that
has a fake ActiveXObject constructor it becomes very important to test
the object returned to ensure that it is an object. The OP's - if (w !=
null) - is a good start but it would also be worth checking that the
object has the methods and properties that the script wants to call (eg.
Documents.Open) in case the ActiveXObject constructor is a fake that
just returns a standard JavaScript object.

But then there are the ActiveX user preferences. My IE 6 will not allow
any scripting of ActiveX over the internet so even if it could be
determined by other means that the browser was IE 6 the script would
still not execute on it.

Just to add to the confusion, I recently read in a netscape.public .*
group of development work on ActiveX for windows Gecko browsers with a
new "GeckoActiveXOb ject" constructor. So maybe this script would not be
limited to just IE in the future. Though I got the impression that the
Gecko ActiveX support would be for custom ActiveX controls and not
Microsoft ones such a Word.Applicatio n.

Richard.

[Lee]

Greener said:

First of all, thanks to all for the assistances!

When I meant it didn't work, I saw on the left bottom corner right
above the toolbar, "Error on Page", after i click a button to do the
following function.

If you're writing JavaScript in Internet Explorer, you should configure
it to show you the details of your errors. I don't use IE often enough
to know how to do that, myself.

[Richard Cornford]

"Lee" <RE************ **@cox.net> wrote in message
news:bm******** @drn.newsguy.co m...
<snip>

If you're writing JavaScript in Internet Explorer, you should
configure it to show you the details of your errors. I don't
use IE often enough to know how to do that, myself.

The quick way to activate IE error messages is to wait until the little
yellow triangle shows up in the browser status bar, double click on it
and, when the message box appears, check the "always show errors"
checkbox it contains.

Otherwise it is in one of the tabs under "Internet Options" in the menu.

Richard.