Quick test for ActiveX?
in [ASP]
|
From: Bob Barrows on 2 Sep 2009 15:41 Neil Gould wrote: > I'm talking about IE (it would be sufficient to limit users to IE for > this purpose if the problem remains indeterminate and no other > solution can be found). The upload operation reliably fails with IE > >= 6 if ActiveX is globally disabled and fails with any browser that > doesn't support ActiveX, e.g. FireFox (don't know about the various > ActiveX emulators for FF). That's where I started with all this, and > what drove me here. > So all I would need to do is run my repro in FF and it should fail? I'll do that when I get home tonight. -- HTH, Bob Barrows
From: Mark McGinty on 11 Sep 2009 17:15 "Neil Gould" <neil(a)myplaceofwork.com> wrote in message news:e6exxh0KKHA.1336(a)TK2MSFTNGP05.phx.gbl... > 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)? The direct answer to your question is, you must clear the kill bit in the registry on the client system. I can never remember the exact key, so this is how I find it: Search the registry for "ADODB.Stream"; Copy its CLSID into the clipboard; Select the key after HKLM\Software\Classes in regedit; Search for the CLSID from there (paste from clipboard into search); This will take you to the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{00000566-0000-0010-8000-00AA006D2EA4} Under that is a DWORD item named Compatibility flags. The value 0x0400 is the imfamous kill bit; set it to 0, kill bit is clear, ADODB.Stream rides again. (You must close all open instances of IE before it takes affect.) But be advised that every single time a new kill bit is added to the list of patches, Windows Update will break ADODB.Stream again. Now as for the rest of the thread (that has been posted since I was last here)... wow, a storm of confusion! My comments pertained exclusively to use of ADO in client side script (assumed to be running in the context of an HTML document, rendered by IE.) If you create an ADO object in code in a SCRIPT tag (that does not set the runat=server attribute) then that object is created on the client. Whether or not ASP was used to emit that script is of no consequence. I think the lines get blurred when we fail to consider what's being rendered to the response (which may well include some script code) as opposed to what's running on the server. A conscious effort must be made to clearly understand which side everything is running on. (A debugger can be of great assistance, when trying to visualize this.) Bob, I assumed that he has some client-side ADO usage based on the way he described the problem, and how/when it manifested. If the problem was\is affected by changes to browser ActiveX settings, and the operative object is ADODB, then by definition he must be using client-side ADO (whether he realizes it or not.) Also, the scenario he described was familiar, I have had occasion to use client-side ADO, and I've even used the Stream [with a Recordset] to upload binary content to SQL image fields. (I realize storing files in the db is not considered a 'best practice', but assert that it can be the best solution in some scenarios.) With binary data Recordset.Field(x).SetChunk cannot be used in a script, because there is no reliable way to read the binary data from file to a variable. ADODB.Stream.LoadFromFile, otoh, does load binary data, and the return of the Read method can be assigned to a long-binary field's value property. The Recordset can then be persisted to XML and sent to the server; the persistance provider encodes the binary data as hex-text. (A server-side Stream could be used to write the binary data to file.) This combination of client-side and server-side ADO makes some sense when the data is going directly into a db, but as we've established, using a stream on the client is impractical for all but a very obscure niche (that can tolerate ongoing random breakage that requires user intervention to fix.) Otoh, it does not make sense when uploading to the server's file system, posting the file in a form, and calling BinaryRead to get it from the request is entirely more practical, and more efficient as well. The only trick is stripping the MIME header off of the data. A server-side ADODB.Stream comes in damn handy when performing this task, but as Bob has said [in an extreme number of different ways] that is not affected in any way by client browser settings (it merely adds yet another layer of semantics confusion.) :-) Hope this clears it up at least to some degree. (Apologies for not watching this thread a little more closely.) -Mark > -- > Neil > > > > >
From: Neil Gould on 12 Sep 2009 06:35 Mark, Mark McGinty wrote: > "Neil Gould" <neil(a)myplaceofwork.com> wrote in message > news:e6exxh0KKHA.1336(a)TK2MSFTNGP05.phx.gbl... >> 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)? > > The direct answer to your question is, you must clear the kill bit in > the registry on the client system. I can never remember the exact > key, so this is how I find it: > > Search the registry for "ADODB.Stream"; > Copy its CLSID into the clipboard; > Select the key after HKLM\Software\Classes in regedit; > Search for the CLSID from there (paste from clipboard into search); > > This will take you to the key: > > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX > Compatibility\{00000566-0000-0010-8000-00AA006D2EA4} > > Under that is a DWORD item named Compatibility flags. The value > 0x0400 is the imfamous kill bit; set it to 0, kill bit is clear, > ADODB.Stream rides again. (You must close all open instances of IE > before it takes affect.) > > But be advised that every single time a new kill bit is added to the > list of patches, Windows Update will break ADODB.Stream again. > > > Now as for the rest of the thread (that has been posted since I was > last here)... wow, a storm of confusion! My comments pertained > exclusively to use of ADO in client side script (assumed to be > running in the context of an HTML document, rendered by IE.) If you > create an ADO object in code in a SCRIPT tag (that does not set the > runat=server attribute) then that object is created on the client. > Whether or not ASP was used to emit that script is of no consequence. > > I think the lines get blurred when we fail to consider what's being > rendered to the response (which may well include some script code) as > opposed to what's running on the server. A conscious effort must be > made to clearly understand which side everything is running on. (A > debugger can be of great assistance, when trying to visualize this.) > > Bob, I assumed that he has some client-side ADO usage based on the > way he described the problem, and how/when it manifested. If the > problem was\is affected by changes to browser ActiveX settings, and > the operative object is ADODB, then by definition he must be using > client-side ADO (whether he realizes it or not.) > > Also, the scenario he described was familiar, I have had occasion to > use client-side ADO, and I've even used the Stream [with a Recordset] > to upload binary content to SQL image fields. (I realize storing > files in the db is not considered a 'best practice', but assert that > it can be the best solution in some scenarios.) > > With binary data Recordset.Field(x).SetChunk cannot be used in a > script, because there is no reliable way to read the binary data from > file to a variable. ADODB.Stream.LoadFromFile, otoh, does load > binary data, and the return of the Read method can be assigned to a > long-binary field's value property. The Recordset can then be > persisted to XML and sent to the server; the persistance provider > encodes the binary data as hex-text. (A server-side Stream could be > used to write the binary data to file.) > > This combination of client-side and server-side ADO makes some sense > when the data is going directly into a db, but as we've established, > using a stream on the client is impractical for all but a very > obscure niche (that can tolerate ongoing random breakage that > requires user intervention to fix.) > > Otoh, it does not make sense when uploading to the server's file > system, posting the file in a form, and calling BinaryRead to get it > from the request is entirely more practical, and more efficient as > well. The only trick is stripping the MIME header off of the data. > A server-side ADODB.Stream comes in damn handy when performing this > task, but as Bob has said [in an extreme number of different ways] > that is not affected in any way by client browser settings (it merely > adds yet another layer of semantics confusion.) :-) > > Hope this clears it up at least to some degree. (Apologies for not > watching this thread a little more closely.) > > > -Mark > Thanks, once again for a thorough explanation. This is the exact method employed by the upload script, so I believe you have a solid grip on what I've been experiencing. I obviously haven't been clear in my presentation, and that lead to much confusion about the server-side vs. client-side matters. I thought that all ASP was server-side only, and couldn't be affected by browser settings, but the odd instance of what I've observed with non-ActiveX enabled browsers threw me for a loop. I will look to see whether "runat=server" is explicitly set in the script, and keep my fingers crossed that this will clear up the problem, as it makes little sense to try to fix it on the client side, and it would be nice to get beyond IE in our environment anyway. -- Best, Neil
From: Neil Gould on 18 Sep 2009 11:13 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? >>> >> Here is another repro using clsupload. Exactly what do I have to >> disable in my browser to make this stop working? >> >> <%@ Language=VBScript %> >> <!--#INCLUDE FILE="clsupload.asp"--> >> >> >> <% >> >> set o = new clsUpload >> if o.Exists("cmdSubmit") then >> >> 'get client file name without path >> sFileSplit = split(o.FileNameOf("txtFile"), "\") >> sFile = sFileSplit(Ubound(sFileSplit)) >> >> o.FileInputName = "txtFile" >> o.FileFullPath = Server.MapPath(".") & "\" & sFile >> >> o.save >> >> if o.Error = "" then >> response.write "Success. File save Thank You for the file." >> else >> response.write "Failed due to the following error: " & o.Error >> end if >> >> end if >> set o = nothing >> %> >> >> >> <HTML> >> <HEAD> >> </HEAD> >> <BODY> >> >> <FORM action="" method=POST id=form1 name=form1 >> ENCTYPE="multipart/form-data"> >> <INPUT type="file" id=text1 name=txtFile> >> <INPUT type="submit" value="Submit" id=submit1 name=cmdSubmit> >> </FORM> >> </BODY> >> </HTML> >> > Thanks, Bob... > > I'll look into it and let you know. > To follow up: The variant of clsUpload associated with this approach does work with FireFox and non ActiveX enabled browsers. In comparing this variant with the one currently in use (that creates a BLOB object), one functional difference aside from the ActiveX issue is that the ASP processing code in this one doesn't work if separated from the form. For example, having a form action = "someASPfile" that uses the above ASP code and includes clsupload.asp results in the process failing due to the "object" being closed. So, to go this route, I have to replicate the processing and error trapping code within each form page instead of using a common ASP-only (e.g. no HTML content) file to execute the tasks. But, this is an acceptable trade-off. Thanks, again to you and Mark for your help as I at least have a possible solution at hand. Neil
From: Bob Barrows on 19 Sep 2009 07:15
Neil Gould wrote: >>> Here is another repro using clsupload. Exactly what do I have to >>> disable in my browser to make this stop working? >>> >>> <%@ Language=VBScript %> >>> <!--#INCLUDE FILE="clsupload.asp"--> >>> > In comparing this variant with the one currently in use (that creates > a BLOB object), one functional difference aside from the ActiveX > issue is that the ASP processing code in this one doesn't work if > separated from the form. For example, having a form action = > "someASPfile" that uses the above ASP code and includes clsupload.asp > results in the process failing due to the "object" being closed. > This does not sound good either. I have several pages working that use this approach (a file-processing page that handles requests from several form pages). Could you show me exactly what I have to do in this ASP code to reproduce your symptoms? Here it is again (I'm leaving out the form because it should not be relevant): <%@ Language=VBScript %> <!--#INCLUDE FILE="clsupload.asp"--> <% set o = new clsUpload if o.Exists("cmdSubmit") then 'get client file name without path sFileSplit = split(o.FileNameOf("txtFile"), "\") sFile = sFileSplit(Ubound(sFileSplit)) o.FileInputName = "txtFile" o.FileFullPath = Server.MapPath(".") & "\" & sFile o.save if o.Error = "" then response.write "Success. File save Thank You for the file." else response.write "Failed due to the following error: " & o.Error end if end if set o = nothing %> -- 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" |