Quick test for ActiveX?
in [ASP]
|
From: Bob Barrows on 31 Aug 2009 12:37 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. > 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 ... > <script type="text/javascript">obj=new ActiveXObject("...")</script> <script type="text/vbscript">set obj=CreateObject("...")</script> > 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 ... -- 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 17:40 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. >> but file transfers don't. > > ?? 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
From: Bob Barrows on 31 Aug 2009 17:59 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. > >>> but file transfers don't. >> >> ?? 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 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. -- 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: Bob Barrows on 31 Aug 2009 19:02 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: <%@ 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. -- 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 1 Sep 2009 07:57
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: > > <%@ 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 |