Can I use/reference an OCX in a different way?
in [Visual Basic]
|
From: Paul Clement on 30 Oct 2009 10:27 On Fri, 30 Oct 2009 00:08:52 -0600, "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote: � "Schmidt" <sss(a)online.de> wrote: � � >Aside from 'Nobodys' suggestions you can also take � >a look at: � >http://www.molebox.com/ � � Now if MS does stop including the VB6 runtime in Windows 8 I wonder if � this could be used to include the VB6 runtime with your app? It might be a moot point if there is no 32-bit version of, or subsystem in, the next version of the OS. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Nobody on 30 Oct 2009 12:08 "Henning" <computer_hero(a)coldmail.com> wrote in message news:ur2HlVWWKHA.5208(a)TK2MSFTNGP05.phx.gbl... > Would it not be possible to create the folder ex. C:\MyApp, copy > MSFLXGRD.OCX there, and in Project Components browse to C:\MyApp and add > *that* MSFLXGRD.OCX as the component to use, without registering? > > It would demand the app to always run in that foldername though. That doesn't work. VB would register the component that you would browse to, so you would have the same problems as I explained previously.
From: Nobody on 30 Oct 2009 12:18 "Nobody" <nobody(a)nobody.com> wrote in message news:e43$P8MWKHA.844(a)TK2MSFTNGP05.phx.gbl... > "Kev Provance" <asdf(a)asdf.asdf> wrote in message > news:OmkzLzMWKHA.4140(a)TK2MSFTNGP06.phx.gbl... >> If you want a hack solution, put the OCX file in your apps dir and >> register >> it when you start your app, before loading any interface (ie Sub Main) > > There are two problems with this, you probably know this, but didn't give > the problem enough time: > > 1 - Installing OCX (without reg free com) to anywhere but what the author > recommends is a bad idea. All applications will start using this version > even if it's an older version. For the OP's case, he needs to check the > file version and install into the System folder if the file being > installed is newer. > > 2 - Registering ActiveX files requires Power Users or higher. In case of > Vista+, it would fail unless the user used "Run as Administrator", or a > second EXE is used that has "asAdministrator" manifest. In these cases, an > elevation prompt shows up. > I forgot to mention that when you run a compiled VB6 app that refers to OCX that is unregistered, it attempts to auto register it. I am not sure if the code that does this is added to the EXE or OCX. This means that the application will work fine once a Power User or Admin(elevated admin in Vista+) start your app once. You still can't put the OCX in the same folder as the EXE unless it's yours, as explained in item 1 above. VB6 compiled apps don't auto register ActiveX DLL/EXE files, only OCX files.
From: Karl E. Peterson on 30 Oct 2009 15:48 Paul Clement wrote: > � Now if MS does stop including the VB6 runtime in Windows 8 I wonder if > � this could be used to include the VB6 runtime with your app? > > It might be a moot point if there is no 32-bit version of, or subsystem in, the > next version of the OS. LOL! Reaching for that Golden Ring, are ya, Paul? Fearmongering at it's finest, yessiree... -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 30 Oct 2009 15:55
Tony Toews [MVP] wrote: > Now if MS does stop including the VB6 runtime in Windows 8 I wonder if > this could be used to include the VB6 runtime with your app? A common misconception about the VB runtime is that it needs to be installed/registered. Just not the case. You can run a ClassicVB application directly off a CD if the runtime exists in the same folder as the exe, just as it would work with any other standard DLL. It's really that simple, until you start dragging other ActiveX stuff into it. -- ..NET: It's About Trust! http://vfred.mvps.org |