Quick test for ActiveX?
in [ASP]
|
From: Neil Gould on 31 Aug 2009 08:40 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, -- Neil Gould Terra Tu Technical Publishing www.TerraTu.com
From: Bob Barrows on 31 Aug 2009 09:04 Neil Gould wrote: > 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. -- Microsoft MVP - ASP/ASP.NET - 2004-2007 Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
From: Neil Gould on 31 Aug 2009 11:03 Bob Barrows wrote: > Neil Gould wrote: >> 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. > 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
From: Bob Barrows on 31 Aug 2009 11:35 Neil Gould wrote: > Bob Barrows wrote: >> Neil Gould wrote: >>> 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. >> > 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. -- Microsoft MVP - ASP/ASP.NET - 2004-2007 Please reply to the newsgroup. This email account is my spam trap so I don't check it very often. If you must reply off-line, then remove the "NO SPAM"
From: Neil Gould on 31 Aug 2009 12:03
Bob Barrows wrote: > Neil Gould wrote: >> Bob Barrows wrote: >>> Neil Gould wrote: >>>> 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. >>> >> 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. > 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 |