469,578 Members | 1,863 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,578 developers. It's quick & easy.

Calling VBScript from JavaScript

Hi guys

I am writing a Javascript routine to check for the presence and version of
an Adobe Acrobat PDFViewer on the user's machine. No problem with any
browser on the Mac, no problem with any browser on Windows - except MSIE.

However, I can write a routine in VBScript to cover the MSIE requirement. So
that's cool.

Both the js and vb elements work fine. So I have no problem with core
functionality.

Naturally, my js and vb scripts are in different files and I reference each
of these in the <head> of the HTML document that contains the js function
that makes the initial call.

The initial call is made to a js routine called "checkPDFViewer()". This
calls another js routine called "getAcrobatVersionJS()". This first of all
checks the platform and if it is not one that it knows about, it simply
returns -1. This result is the cue for "checkPDFViewer()" to call the vb
routine "getAcrobatVersionVB()".

Thus...

function checkPDFViewer () {
acrobatVersion = getAcrobatVersionJS();

if (acrobatVersion > -1) {
return true;
}
else {
acrobatVersion = getAcrobatVersionVB();

if (acrobatVersion > -1) {
return true;
}
else {
return false;
}
}
}

The problem is that I get an unknown object being thrown at me by MSIE.

What am I doing wrong? Like I say, individually the various code elements do
what they are supposed to do. I can run them in test harness HTML and they
return the results I expect. The problems arise when I try and work them
together.
Many thanks in advance

Ian

Jul 23 '05 #1
4 10651
Ian Sedwell wrote:
Hi guys

I am writing a Javascript routine to check for the presence and version of
an Adobe Acrobat PDFViewer on the user's machine. No problem with any
browser on the Mac, no problem with any browser on Windows - except MSIE.

However, I can write a routine in VBScript to cover the MSIE requirement. So
that's cool.

Both the js and vb elements work fine. So I have no problem with core
functionality.

Naturally, my js and vb scripts are in different files and I reference each
of these in the <head> of the HTML document that contains the js function
that makes the initial call.

The initial call is made to a js routine called "checkPDFViewer()". This
calls another js routine called "getAcrobatVersionJS()". This first of all
checks the platform and if it is not one that it knows about, it simply
returns -1. This result is the cue for "checkPDFViewer()" to call the vb
routine "getAcrobatVersionVB()".

Thus...

function checkPDFViewer () {
acrobatVersion = getAcrobatVersionJS();

if (acrobatVersion > -1) {
return true;
}
else {
acrobatVersion = getAcrobatVersionVB();

if (acrobatVersion > -1) {
return true;
}
else {
return false;
}
}
}

The problem is that I get an unknown object being thrown at me by MSIE.

What am I doing wrong? Like I say, individually the various code elements do
what they are supposed to do. I can run them in test harness HTML and they
return the results I expect. The problems arise when I try and work them
together.
Many thanks in advance

Ian

Hi,

As far as I am aware, the two can't talk to each other.
I don't think you can make them, however hard you'd try.
Try changing a hidden field and call the VBs bythe onchange, perhaps?

Kien
Jul 23 '05 #2
In article <BC***********************@btclick.com>,
ia*********@btclick.com enlightened us with...
Hi guys

I am writing a Javascript routine to check for the presence and version of
an Adobe Acrobat PDFViewer on the user's machine. No problem with any
browser on the Mac, no problem with any browser on Windows - except MSIE.


If you want code to run only in IE, you can use conditional comments
instead of trying to hack it into a javascript that is meant to run in
all browsers.

Why not use that?

http://msdn.microsoft.com/workshop/a...comment_ovw.as
p

Modify this to call your VB function (outside of the rest of your
script).

<!--[if IE 5]>
<SCRIPT LANGUAGE="Javascript">
alert("Congratulations. You are running IE5 or later!");
</SCRIPT>
<P>Thank you for closing the message box.</P>
<![endif]-->

--
--
~kaeli~
Contrary to popular opinion, the plural of 'anecdote' is
not 'fact'.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

Jul 23 '05 #3


Ian Sedwell wrote:

I am writing a Javascript routine to check for the presence and version of
an Adobe Acrobat PDFViewer on the user's machine. No problem with any
browser on the Mac, no problem with any browser on Windows - except MSIE.

However, I can write a routine in VBScript to cover the MSIE requirement. So
that's cool.
There shouldn't be anything your VBScript in a HTML page in IE does that
you couldn't do with JavaScript in a HTML page in IE.
Both the js and vb elements work fine. So I have no problem with core
functionality.

Naturally, my js and vb scripts are in different files and I reference each
of these in the <head> of the HTML document that contains the js function
that makes the initial call.

The initial call is made to a js routine called "checkPDFViewer()". This
calls another js routine called "getAcrobatVersionJS()". This first of all
checks the platform and if it is not one that it knows about, it simply
returns -1. This result is the cue for "checkPDFViewer()" to call the vb
routine "getAcrobatVersionVB()".

Thus...

function checkPDFViewer () {
acrobatVersion = getAcrobatVersionJS();

if (acrobatVersion > -1) {
return true;
}
else {
acrobatVersion = getAcrobatVersionVB();

if (acrobatVersion > -1) {
return true;
}
else {
return false;
}
}
}

The problem is that I get an unknown object being thrown at me by MSIE.
On what line?
How does the VBScript code look like?
Better yet put the example page online and post a URL. It can have
various reasons, for instance the order of your script elemens with the
language determines which language IE/Win assumes as the scripting
language for event handlers.
What am I doing wrong? Like I say, individually the various code elements do
what they are supposed to do. I can run them in test harness HTML and they
return the results I expect. The problems arise when I try and work them
together.


Just be aware that all those plugin checks are prone to fail for various
reasons, you can set up other applications than Adobe Acrobat viewer to
view PDF files on a machine, you can set up Adobe Acrobat viewer as an
application but disable it as a plugin for Mozilla/Netscape for instance.

--

Martin Honnen
http://JavaScript.FAQTs.com/

Jul 23 '05 #4
DU
Ian Sedwell wrote:
Hi guys

I am writing a Javascript routine to check for the presence and version of
an Adobe Acrobat PDFViewer on the user's machine. No problem with any
browser on the Mac, no problem with any browser on Windows - except MSIE.

I would first search very carefully the adobe.com site looking for
reliable answers on this. It's not that people who replied to you are
not capable or anything. I just feel that the first step would be to
examine carefully what adobe.com proposes regarding detection of Acrobat
presence and version.

There is an entirely different approach too. Let the user know that this
link or that link is a .pdf resource. That way, he can make the decision
on his own (1). Use a small image to indicate a .pdf file on the right
side of the link; use the title attribute to indicate so in the <a>
element. Also, provide an html alternative for users who do not have
acrobat reader installed or who don't want to fire acrobat reader or
whatever reason.

Once browsers support well CSS3 selectors and will want to hard-code
cursors to identify links accordingly, then

a[href$=".pdf"]:not([onclick]) {cursor: downloadpdf.cur !important, auto;}

Whatever you do, your code (and webpage requirements, goals) should be
working in a script disabled/non-existent environment and should provide
an alternative to .pdf file. There are a lot of usability studies
available already documenting that .pdf are disliked by a wide majority
of users.

DU
--
(1)
"if your link spawns a new window, or causes another windows to "pop up"
on your display, or move the focus of the system to a new FRAME or
Window, then the nice thing to do is to tell the user that something
like that will happen." W3C Accessibility Initiative regarding popups
I'd say the same for links which fire Acrobat Reader and start a
download of a - even moderate size - .pdf file.
"Use link titles to provide users with a preview of where each link will
take them, before they have clicked on it." Ten Good Deeds in Web
Design, J. Nielsen

However, I can write a routine in VBScript to cover the MSIE requirement. So
that's cool.

Both the js and vb elements work fine. So I have no problem with core
functionality.

Naturally, my js and vb scripts are in different files and I reference each
of these in the <head> of the HTML document that contains the js function
that makes the initial call.

The initial call is made to a js routine called "checkPDFViewer()". This
calls another js routine called "getAcrobatVersionJS()". This first of all
checks the platform and if it is not one that it knows about, it simply
returns -1. This result is the cue for "checkPDFViewer()" to call the vb
routine "getAcrobatVersionVB()".

Thus...

function checkPDFViewer () {
acrobatVersion = getAcrobatVersionJS();

if (acrobatVersion > -1) {
return true;
}
else {
acrobatVersion = getAcrobatVersionVB();

if (acrobatVersion > -1) {
return true;
}
else {
return false;
}
}
}

The problem is that I get an unknown object being thrown at me by MSIE.

What am I doing wrong? Like I say, individually the various code elements do
what they are supposed to do. I can run them in test harness HTML and they
return the results I expect. The problems arise when I try and work them
together.
Many thanks in advance

Ian

Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Kim Forbes | last post: by
1 post views Thread by Ian Sedwell | last post: by
reply views Thread by Petrucci2000 | last post: by
1 post views Thread by P K | last post: by
2 posts views Thread by rodchar | last post: by
3 posts views Thread by MicroMoth | last post: by
5 posts views Thread by Newbie Coder | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.