By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,635 Members | 2,085 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,635 IT Pros & Developers. It's quick & easy.

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

P: n/a
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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.indexOf("MSIE")!=-1)
{
var w = new ActiveXObject("Word.Application");
if (w != null)
{
w.Visible = true;

w.Documents.Open(file);

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

}
</script>

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

Helena
Jul 20 '05 #1
Share this Question
Share on Google+
10 Replies


P: n/a
In article <9c*************************@posting.google.com> ,
he********@yahoo.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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.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.getElementById &! 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
Jul 20 '05 #2

P: n/a
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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.indexOf("MSIE")!=-1)
{
var w = new ActiveXObject("Word.Application");
if (w != null)
{
w.Visible = true;

w.Documents.Open(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?

Jul 20 '05 #3

P: n/a
"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m11.aol.com...
In article <9c*************************@posting.google.com> ,
he********@yahoo.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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.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.getElementById &! 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.ActiveXObject){
// 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 "GeckoActiveXObject" 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.Application.

Richard.
Jul 20 '05 #4

P: n/a
In article <bl*******************@news.demon.co.uk>, "Richard Cornford"
<Ri*****@litotes.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
ActiveXObject constructor:-

if(window.ActiveXObject){
// 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
Jul 20 '05 #5

P: n/a
"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.
Jul 20 '05 #6

P: n/a
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.com>...
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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.indexOf("MSIE")!=-1)
{
var w = new ActiveXObject("Word.Application");
if (w != null)
{
w.Visible = true;

w.Documents.Open(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?

Jul 20 '05 #7

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

w.Documents.Open(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*****@litotes.demon.co.uk> wrote in message news:<bl*******************@news.demon.co.uk>...
"HikksNotAtHome" <hi************@aol.com> wrote in message
news:20***************************@mb-m11.aol.com...
In article <9c*************************@posting.google.com> ,
he********@yahoo.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="JavaScript">
function doWord(file)
{

if (navigator.userAgent.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.getElementById &! 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.ActiveXObject){
// 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 "GeckoActiveXObject" 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.Application.

Richard.

Jul 20 '05 #8

P: n/a
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.

Jul 20 '05 #9

P: n/a
"Lee" <RE**************@cox.net> wrote in message
news:bm********@drn.newsguy.com...
<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.
Jul 20 '05 #10

P: n/a
"Greener" <he********@yahoo.com> wrote in message
news:9c**************************@posting.google.c om...
Thanks a lot. I tried to insert the following piece of code
to my code in several possible places: if(window.ActiveXObject){
// new ActiveXObject can be called.
}
<script language="JavaScript">
function doWord(file)
{
if(window.ActiveXObject){
if (navigator.userAgent.indexOf("MSIE")!=-1)
You have missed the point of Randy's original reply to your post. You do
not _ever_ make decisions based on the userAgent string. The only
information that can be gleaned from the contents of the user agent
string is what the user agent string contains, and that gets you
nowhere.

The point is to replace the meaningless userAgent string based test with
one that has a genuine relationship to your problem. So, assuming that
the required task is to instanciate an ActiveX objet the meaningful
_first_ test is to see if the browser has an ActiveXObject constructor.
Then you can call the ActiveXObject constructor, but the test tells you
nothing more than that the ActiveXObject constructor exists, the outcome
of the call still needs to be tested (assuming that the call itself does
not throw and exception).

<snip>What went wrong? How to make it work? Bear with me
and sorry for my ignorance.


To know what went wrong I would need to know what happened, such things
as error messages, the context of testing and so on.

Richard.
Jul 20 '05 #11

This discussion thread is closed

Replies have been disabled for this discussion.