Quick test for ActiveX?

[Neil Gould]

Hi all,

One of our sites use classic ASP, and has been running without major
problems. However, some users are getting errors with some ADO functions
after "upgrading" to IE8, and I suspect that the issue is related to ActiveX
not being enabled on their system, as I can generate the same error by
disabling ActiveX or using a browser that doesn't support ActiveX. Anyone
know of a quick-and-not-so-dirty way to test for ActiveX using classic ASP?

Thanks,

 

[Bob Barrows]

Hi all,

One of our sites use classic ASP, and has been running without major
problems. However, some users are getting errors with some ADO
functions after "upgrading" to IE8, and I suspect that the issue is
related to ActiveX not being enabled on their system, as I can
generate the same error by disabling ActiveX or using a browser that
doesn't support ActiveX. Anyone know of a quick-and-not-so-dirty way
to test for ActiveX using classic ASP?

No, ASP is server-side technology so by definition it can't be used to test
client capabilities.

You will need to use client-side code for this. There is nothing beyond
trying to create an ADO object and trapping the error that occurs.

 

[Neil Gould]

No, ASP is server-side technology so by definition it can't be used
to test client capabilities.

You will need to use client-side code for this. There is nothing
beyond trying to create an ADO object and trapping the error that
occurs.

Thanks, Bob,

I might have been clearer... your suggestion is what I had in mind. I
realize that ASP is server-side tech, and hoped that there might be a way to
initiate an action via script that would require ActiveX, then trap the
error if it isn't available.

Neil

 

[Bob Barrows]

Thanks, Bob,

I might have been clearer... your suggestion is what I had in mind. I
realize that ASP is server-side tech, and hoped that there might be a
way to initiate an action via script that would require ActiveX, then
trap the error if it isn't available.

I'm not really sure what you are asking. You already have a line of
client-side code that tries to initiate an adodb object don't you? Just trap
the error that is raised by that line of code using try...catch if jscript
or on error resume next if vbscript.

 

[Neil Gould]

I'm not really sure what you are asking. You already have a line of
client-side code that tries to initiate an adodb object don't you?
Just trap the error that is raised by that line of code using
try...catch if jscript or on error resume next if vbscript.

I'm trying to find a solution that "anticipates" a problem before the client
initiates an action. Put another way, not all of the ado objects seem to
need activex on the client side to run. For example, database operations
work from browsers that don't support activex, but file transfers don't. So
I'm hoping that someone knows which objects do and don't require activex on
the client as a starting point, and ultimately I'd like to be able to
initiate an action via server-side script that requires it so that I can
trap that error.

Thanks,

Neil

 

[Bob Barrows]

Bob Barrows wrote:
I'm trying to find a solution that "anticipates" a problem before the
client initiates an action.

That's the point I'm trying to make: you won't find it.

Put another way, not all of the ado
objects seem to need activex on the client side to run.

??? ADO is an ActiveX technology. What ADO object does not require an
ActiveX instantiation?

For example,
database operations work from browsers that don't support activex,

??? In client-side code? Can you give me an example?

but file transfers don't.

?? File transfers don't need client-side activex, unless you're using an
activex client-side download manager

So I'm hoping that someone knows which
objects do and don't require activex on the client as a starting

ActiveX objects, by definition, require activex to be enabled in the browser
if you wish to run them in client-side code (not really sure why you need to
perform database operations in client-side code ... at the least, this is a
security hole)

So, if any of the following exists in the html being processed by a browser,
then activex needs to be enabled:

<OBJECT ... >

point, and ultimately I'd like to be able to initiate an action via
server-side script that requires it so that I can trap that error.

Impossible. I thought you said you understood the demarcation between
client-side and server-side execution. The server code knows nothing about
the client capabilities beyond what is passed in the Request object ...
Sure, you can response.write a script block to be executed on the client,
but you don't need ASP to do that ...

 

[Neil Gould]

That's the point I'm trying to make: you won't find it.

I'm getting that impression.

??? ADO is an ActiveX technology. What ADO object does not require an
ActiveX instantiation?


??? In client-side code? Can you give me an example?

Login procedures and certain updates initiated by client-side actions.

?? File transfers don't need client-side activex, unless you're using
an activex client-side download manager

The various "pure ASP" upload processes I've worked with require it. They
fail to pull filename information from
<input type="file" ... > if it is unavailable.

I can accept that what I was wanting to do may not be possible, and am only
trying to expand my understanding of the ADO realm, not start an argument
about it all...

Thanks again for your help.

Neil

 

[Bob Barrows]

I'm getting that impression.

Login procedures and certain updates initiated by client-side actions.

Please, provide an example. Are the database activities you are talking
about occurring in client-side or server-side code? I can guarantee you that
server-side ADO code absolutely does not depend on browser capabilities.

The various "pure ASP" upload processes I've worked with require it.
They fail to pull filename information from
<input type="file" ... > if it is unavailable.

I don't think so. That input tag is pure html. It should not depend on
activex being enabled. Now maybe, just maybe ... IE is using a COM object to
cause the browse dialog to appear ... I'm going to test this after I send
this.

I can accept that what I was wanting to do may not be possible, and
am only trying to expand my understanding of the ADO realm, not start
an argument about it all...

I'm sorry it appeared I was arguing. I'm trying to get you to clarify what
you are trying to accomplish. Some of the statements you made make no sense.

 

[Bob Barrows]

The various "pure ASP" upload processes I've worked with require it.
They fail to pull filename information from
<input type="file" ... > if it is unavailable.

Here is a simple repro to allow you to see that what you are thinking is
incorrect:

<%@ Language=VBScript %>
<%
biData = Request.BinaryRead(Request.TotalBytes)
Response.Write CWideString(biData)
Function CWideString(bsString)
Dim nIndex
CWideString =""
For nIndex = 1 to LenB(bsString)
CWideString = CWideString & Chr(AscB(MidB(bsString,nIndex,1)))
Next
End Function

%>
<HTML>
<HEAD>
</HEAD>
<BODY>

<FORM action="" method=POST id=form1 name=form1
ENCTYPE="multipart/form-data">
<INPUT type="file" id=text1 name=text1>
<INPUT type="submit" value="Submit" id=submit1 name=submit1>
</FORM>
</BODY>
</HTML>

When I run this after disabling activex in my browser, it correctly uploads
the selected file and displays the string that can be parsed to get the file
name. For example, here is the string that results from uploading a small
file:

-----------------------------7d9092205d0 Content-Disposition: form-data;
name="text1"; filename="F:\INSTALL.LOG" Content-Type:
application/octet-stream *** Installation Started 08/10/2009 22:43 ***
Title: Rhapsody Installation Source: f:\Temp\GLB2DB.tmp | 08-10-2009 |
22:43:04 | 71680 User Rights: Admin -----------------------------7d9092205d0
Content-Disposition: form-data; name="submit1"
Submit -----------------------------7d9092205d0--


Now if your "pure ASP" upload process includes an activex progress bar, then
yes, killing activex will kill that. To my mind, a solution that uses such a
control can hardly be called "pure" ASP.

 

[Neil Gould]

Here is a simple repro to allow you to see that what you are thinking
is incorrect:

<%@ Language=VBScript %>
<%
biData = Request.BinaryRead(Request.TotalBytes)
Response.Write CWideString(biData)
Function CWideString(bsString)
Dim nIndex
CWideString =""
For nIndex = 1 to LenB(bsString)
CWideString = CWideString & Chr(AscB(MidB(bsString,nIndex,1)))
Next
End Function

%>
<HTML>
<HEAD>
</HEAD>
<BODY>

<FORM action="" method=POST id=form1 name=form1
ENCTYPE="multipart/form-data">
<INPUT type="file" id=text1 name=text1>
<INPUT type="submit" value="Submit" id=submit1 name=submit1>
</FORM>
</BODY>
</HTML>

When I run this after disabling activex in my browser, it correctly
uploads the selected file and displays the string that can be parsed
to get the file name. For example, here is the string that results
from uploading a small file:

-----------------------------7d9092205d0 Content-Disposition:
form-data; name="text1"; filename="F:\INSTALL.LOG" Content-Type:
application/octet-stream *** Installation Started 08/10/2009 22:43 ***
Title: Rhapsody Installation Source: f:\Temp\GLB2DB.tmp | 08-10-2009 |
22:43:04 | 71680 User Rights: Admin
-----------------------------7d9092205d0 Content-Disposition:
form-data; name="submit1"
Submit -----------------------------7d9092205d0--


Now if your "pure ASP" upload process includes an activex progress
bar, then yes, killing activex will kill that. To my mind, a solution
that uses such a control can hardly be called "pure" ASP.

I'll look into this to understand the differences between your example and
what I currently have. FWIW, there are no progress bars or other such items
in the current code samples which are based on variants of the
"clsUpload.asp" code that can be found at:

http://www.freevbcode.com/ShowCode.asp?ID=4596

Thanks again for your help.

Neil

 

[Neil Gould]

Please, provide an example. Are the database activities you are
talking about occurring in client-side or server-side code? I can
guarantee you that server-side ADO code absolutely does not depend on
browser capabilities.

I think this has gotten a bit twisted, since if I understand your statement,
we are in agreement about this; the login procedures and data updates that
use information pulled from the HTML form work whether or not the user's
browser supports activex.

What I'm trying to get a grip on is why other procedures (e.g. the upload)
fail if activex is not enabled or supported.

Neil

 

[Bob Barrows]

I'll look into this to understand the differences between your
example and what I currently have. FWIW, there are no progress bars
or other such items in the current code samples which are based on
variants of the "clsUpload.asp" code that can be found at:

http://www.freevbcode.com/ShowCode.asp?ID=4596

I've taken a quick browse through that and admittedly I might have
missed something, but there seems to be nothing in there that depends on
a client machine's activex functionality, given that it is all
server-side code. The only problem that might occur is if the client
browser fails to populate the form fields, but again, it's a pure html
form so it should not depend on activex functionality. I've again tried
a repro using this class (I won't bother posting it) and disabling
activex in my browser fails to raise any errors.

I really think you're barking up the wrong tree but I'm willing to be
proven wrong. Show me how to reproduce the errors you are seeing.

 

[Neil Gould]

I've taken a quick browse through that and admittedly I might have
missed something, but there seems to be nothing in there that depends
on a client machine's activex functionality, given that it is all
server-side code. The only problem that might occur is if the client
browser fails to populate the form fields, but again, it's a pure html
form so it should not depend on activex functionality. I've again
tried a repro using this class (I won't bother posting it) and
disabling activex in my browser fails to raise any errors.

I really think you're barking up the wrong tree but I'm willing to be
proven wrong. Show me how to reproduce the errors you are seeing.

I'd have posted a URL if it was practical to do so, but alas, it is not. I
can only tell you that disabling activex causes the process to abort on the
site, and the error appears to be the retrieval of the upload file's info
from the HTML form. But, it wouldn't be the first wrong tree I've barked at
in my 60+ years. ;-) Then again, that's why I'm here now...

Your other post may give insights into a solution that avoids the problem
altogether, and that will suffice.

Thanks again,

Neil

 

[Mark McGinty]

I'm trying to find a solution that "anticipates" a problem before the
client
initiates an action. Put another way, not all of the ado objects seem to
need activex on the client side to run. For example, database operations
work from browsers that don't support activex, but file transfers don't.
So
I'm hoping that someone knows which objects do and don't require activex
on
the client as a starting point, and ultimately I'd like to be able to
initiate an action via server-side script that requires it so that I can
trap that error.

Thanks,

Neil

There are several ActiveX-related settings, many of which only affect a
subset of ActiveX objects. There is a single setting to disable them all,
but the more selective settings still apply even when ActiveX in general is
enabled.

ADODB.Recordset is "marked safe for scripting" but is not included in IE8's
stock "PreApproved" list. The bad news is it may seem awfully hit-and-miss;
the good news is that usually you're only one or two settings changes away
from working. Tell the user how to fix it; if he wants to use your site
badly enough, problem solved. You could also provide a program to do it,
but getting the user to run it then becomes the challenge.

ADODB.Stream, otoh, is not only "not marked as safe for scripting," there is
also a kill bit for it, published via Windows Update (and re-published every
time a new kill bit is added, so you can count on it getting broken again
every time you fix it.) Client-side use of Stream is totally impractical.

Luckilly you can use DOMDocument to do most of what was done with Stream --
handling of binary data being the notable exception. But since you can POST
binary file data to the server without even needing any client-side script
at all, if you absolutely need a Stream, post the data to the server and
create a Stream there.

You mentioned file upload as a problem... if you're loading-up a varbinary
field in a recordset and sending the recordset to the server, to do this you
should know that encoding doubles the size of the data in XML, and if the
XML is Unicode, it doubles it again. Post it in a form and read it from the
request instead, it's significantly more efficient and not that hard to
do... imho, of course.

Bottom line is that no simplistic assumptions about user settings can be
made when a client-side recordset fails, the issue is considerably more
involved than that.


-Mark

btw, you should test creation of the recordset object and opening it
separately. If it can be created then ActiveX permisions are adequate. If,
having successfully created, it fails to open, the relevant setting is
probably "access data across domains".

 

[Neil Gould]

Mark!

There are several ActiveX-related settings, many of which only affect
a subset of ActiveX objects. There is a single setting to disable
them all, but the more selective settings still apply even when
ActiveX in general is enabled.

ADODB.Recordset is "marked safe for scripting" but is not included in
IE8's stock "PreApproved" list. The bad news is it may seem awfully
hit-and-miss; the good news is that usually you're only one or two
settings changes away from working. Tell the user how to fix it; if
he wants to use your site badly enough, problem solved. You could
also provide a program to do it, but getting the user to run it then
becomes the challenge.

ADODB.Stream, otoh, is not only "not marked as safe for scripting,"
there is also a kill bit for it, published via Windows Update (and
re-published every time a new kill bit is added, so you can count on
it getting broken again every time you fix it.) Client-side use of
Stream is totally impractical.

Luckilly you can use DOMDocument to do most of what was done with
Stream -- handling of binary data being the notable exception. But
since you can POST binary file data to the server without even
needing any client-side script at all, if you absolutely need a
Stream, post the data to the server and create a Stream there.

You mentioned file upload as a problem... if you're loading-up a
varbinary field in a recordset and sending the recordset to the
server, to do this you should know that encoding doubles the size of
the data in XML, and if the XML is Unicode, it doubles it again.
Post it in a form and read it from the request instead, it's
significantly more efficient and not that hard to do... imho, of
course.

Bottom line is that no simplistic assumptions about user settings can
be made when a client-side recordset fails, the issue is considerably
more involved than that.


-Mark

btw, you should test creation of the recordset object and opening it
separately. If it can be created then ActiveX permisions are
adequate. If, having successfully created, it fails to open, the
relevant setting is probably "access data across domains".

Thanks very much for this response! It hits the issue I'm wrestling with
squarely on the head. Now, I'll try to absorb your comments to see if there
is a way to address this matter. Could you tell me more about fixing issues
with IE8 and ADODB.Stream (These users do need to transfer binary files to
the site via ASP)?

 

[Bob Barrows]

Luckilly you can use DOMDocument to do most of what was done with
Stream -- handling of binary data being the notable exception. But
since you can POST binary file data to the server without even
needing any client-side script at all, if you absolutely need a
Stream, post the data to the server and create a Stream there.

You mentioned file upload as a problem... if you're loading-up a
varbinary field in a recordset and sending the recordset to the
server, to do this you should know that encoding doubles the size of
the data in XML, and if the XML is Unicode, it doubles it again.
Post it in a form and read it from the request instead, it's
significantly more efficient and not that hard to do... imho, of
course.

Hi Mark,
Good to see you back here - it's been a while.

Good information which I've filed for future reference. Unfortunately,
you've gone to a lot of trouble to answer a question that it turns out
the OP wasn't really asking, since we've finally established that ADO
(and in particular, client-side ADO) was a red herring and the issue he
really is having is where disabling activex prevents the selected file
in the <input type="file"> box from being submitted to the server. I
have failed to reproduce this behavior, but perhaps you could add some
substance.

 

[Bob Barrows]

Mark!

Thanks very much for this response! It hits the issue I'm wrestling
with squarely on the head. Now, I'll try to absorb your comments to
see if there is a way to address this matter. Could you tell me more
about fixing issues with IE8 and ADODB.Stream (These users do need to
transfer binary files to the site via ASP)?

Really? I thought we had established that you were not using ADO in
client-side code? The issues Mark wrote about pertain solely to the use
of ADO objects in client-side code ("Client-side use of Stream is
totally impractical"), and should have no bearing at all on the problem
you described to me.

I really believe we will not get to the bottom of this until we can see
a small repro to allow us to see the behavior you are talking about.
Your earlier suggestion about providing a url would be useless to us
since we would not be able to see the server-side code. My suggestion is
that you create a repro page (or two) that contains only the code and
elements needed for us to see the behavior and post the code here so we
can try to recreate the behavior ourselves.

 

[Neil Gould]

Bob,

Really? I thought we had established that you were not using ADO in
client-side code? The issues Mark wrote about pertain solely to the
use of ADO objects in client-side code ("Client-side use of Stream is
totally impractical"), and should have no bearing at all on the
problem you described to me.

The problem that I am trying to solve is directly addressed by Mark's
information; the IE8 behavior is exactly as he describes, e.g. Recordset
operations work properly without activex and some other operations fail.
Since all of these operations are implemented server-side, hence my original
confusion about which ADOs require activex to be available client-side, as
that is the single repeatable aspect of the problem behavior.

It seems that a solution will most likely come from a couple of directions;
tell IE8 users how to set their browsers to enable activex (again, Mark's
comment about specific bit settings was enlightening), but that is not an
ASP matter; or find an ASP file transfer method that doesn't require
client-side activex, ergo my pursuit of such information here. Given our
dialogue, I'm sure that my questioning has been awkward, and for that I
apologize.

I really believe we will not get to the bottom of this until we can
see a small repro to allow us to see the behavior you are talking
about. Your earlier suggestion about providing a url would be useless
to us since we would not be able to see the server-side code.

My comment was that giving a url isn't _practical_ at this point. The reason
is that the particular ASP code is in an administrative portion of the site
that is not generally accessible, and providing access to it via usenet is,
well, "unwise" comes to mind. Even then, you could observe the behavior with
no more insights into the code, as you've pointed out above.

My
suggestion is that you create a repro page (or two) that contains
only the code and elements needed for us to see the behavior and post
the code here so we can try to recreate the behavior ourselves.

The "ASP upload" code amounts to about 1,000 lines, which is why I tried to
describe the problem behavior and pointed to examples of clsUpload.

I did look into your code example in a previous reply. I'm looking into the
differences between your example and the clsUpload code, as both initially
utilize Request.BinaryRead, so the actual problem may lie somewhere beyond
pulling the file info from the HTML form. But, it all comes back to the
clsUpload code failing if activex is not available client-side.

Thanks for your continued efforts, Bob!

Neil

 

[Bob Barrows]

Bob,


The problem that I am trying to solve is directly addressed by Mark's
information; the IE8 behavior is exactly as he describes, e.g.
Recordset operations work properly without activex and some other

No, no ... you're totally missing the point. He was saying that
_client-side_ recordset operations can fail (he was still confused by your
original question - as I initially was - and had come to the conclusion that
you were using ADO in client-side code). The standard html file selecter
does not use ADO on the client side to transfer files. If it did, users that
did not have MDAC installed would not be able to upload files, now would
they?

operations fail. Since all of these operations are implemented
server-side, hence my original confusion about which ADOs require
activex to be available client-side, as that is the single repeatable
aspect of the problem behavior.

Nowhere did he say that server-side ADO operations could be affected by
browser settings. Please, read it again.

It seems that a solution will most likely come from a couple of
directions; tell IE8 users how to set their browsers to enable
activex (again, Mark's comment about specific bit settings was
enlightening),

That's fine, if they want to go through that, but since it might not be
addressing the actual problem, you might find it coming back to haunt you in
the future. Also, some users may not be as inclined to lower their security
shields as you may be hoping.

I did look into your code example in a previous reply. I'm looking
into the differences between your example and the clsUpload code, as
both initially utilize Request.BinaryRead, so the actual problem may
lie somewhere beyond pulling the file info from the HTML form. But,
it all comes back to the clsUpload code failing if activex is not
available client-side.

But I haven't seen that behavior, yet. The code to retrieve the file name
works fine regardless of my browser settings.
Let's attack the symptom again: I think we've established that the file name
is certainly present in the Request. What is actually failing in the
clsUpload code? An attempt to use ADO to write the file to a database? An
attempt to store it in the server's file system?

 

[Neil Gould]

Bob,

No, no ... you're totally missing the point. He was saying that
_client-side_ recordset operations can fail

Please help me to understand your perspective. As I understand it, the ASP
code in question is _all_ server-side, but some operations behave
differently dependent upon activex settings.

Mark wrote:
"There are several ActiveX-related settings, many of which only affect a
subset of ActiveX objects. There is a single setting to disable them all,
but the more selective settings still apply even when ActiveX in general is
enabled."

Does this not imply that some ADO functions will be affected by activex
settings, others not? If so, is that somehow different from my initial
observation and resultant line of questioning?

Again:
"ADODB.Recordset is "marked safe for scripting" but is not included in IE8's
stock "PreApproved" list. The bad news is it may seem awfully hit-and-miss;
the good news is that usually you're only one or two settings changes away
from working. "

As I read it, this says that settings in IE8 can cause adodb.recordset
operations to fail, but it is possible that some (if not all will succeed)
because the default setting for IE8 will not interrupt the process. Is this
an incorrect interpretation of Mark's message?

And, finally:
"ADODB.Stream, otoh, is not only "not marked as safe for scripting," there
is also a kill bit for it, published via Windows Update (and re-published
every time a new kill bit is added, so you can count on it getting broken
again every time you fix it.)"

This seems consistent with the above, in that ADODB.stream operations are
likely to fail by default due to ActiveX settings, and is consistent with my
observations of the problem.

(he was still confused by
your original question - as I initially was - and had come to the
conclusion that you were using ADO in client-side code).

Sorry for the confusion, but no, I'm not talking about any client-side code,
if by that you mean some custom ASP code installed on a user's machine to
interact with the site.

Nowhere did he say that server-side ADO operations could be affected
by browser settings. Please, read it again.

If I follow you, your interpretation of Mark's quotes above suggests that
all of these ASP operations should succeed regardless of ActiveX settings on
the user's machine because they are server-side operations? Since that isn't
what happens, and success or failure can be determined by ActiveX settings
on the browser, what am I missing?

That's fine, if they want to go through that, but since it might not
be addressing the actual problem, you might find it coming back to
haunt you in the future. Also, some users may not be as inclined to
lower their security shields as you may be hoping.

Exactly my concern. This is why I'm searching out details about the nature
of ADO.

But I haven't seen that behavior, yet. The code to retrieve the file
name works fine regardless of my browser settings.

Well, actually, your code appears to copy the file into the SafeArray and
writes a subset of that information to the browser. Although the filename is
included in that information, so far I haven't been able to extract the
filename alone, though this may be due to the limited time I've had to
explore the possibilities. It may be that the additional code in clsUpload
requires client-side activex, but I can't see where that might be yet.

Let's attack the symptom again: I think we've established that the
file name is certainly present in the Request.
Yes.

What is actually
failing in the clsUpload code? An attempt to use ADO to write the
file to a database? An attempt to store it in the server's file
system?

Well, those certainly are the questions. ;-)

The other question being, why does it succeed when ActiveX is available in
the client-side browser?

Thanks again,

Neil