Quick test for ActiveX?
in [ASP]
|
From: Neil Gould on 1 Sep 2009 08:09 Bob Barrows wrote: > Neil Gould wrote: >> Bob Barrows wrote: >>> Neil Gould wrote: >>>> 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. >>> >> I'm getting that impression. >> >>>> 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? >>> >> 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. > 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
From: Bob Barrows on 1 Sep 2009 09:05 Neil Gould wrote: > Bob Barrows wrote: >> Neil Gould wrote: >>>> >>>> ?? 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. >>> >> Here is a simple repro to allow you to see that what you are thinking >> is incorrect: <snip> >> > 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. -- HTH, Bob Barrows
From: Neil Gould on 1 Sep 2009 09:52 Bob Barrows wrote: > Neil Gould wrote: >> Bob Barrows wrote: >>> Neil Gould wrote: >>>>> >>>>> ?? 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. >>>> >>> Here is a simple repro to allow you to see that what you are >>> thinking is incorrect: > <snip> >>> >> 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. > 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
From: Mark McGinty on 1 Sep 2009 16:25 "Neil Gould" <neil(a)myplaceofwork.com> wrote in message news:OwxjbSlKKHA.1248(a)TK2MSFTNGP04.phx.gbl... > 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 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".
From: Neil Gould on 1 Sep 2009 17:09
Mark! Mark McGinty wrote: > "Neil Gould" <neil(a)myplaceofwork.com> wrote in message > news:OwxjbSlKKHA.1248(a)TK2MSFTNGP04.phx.gbl... >> 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 > > 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)? -- Neil |