Can I use/reference an OCX in a different way?
in [Visual Basic]
|
From: Karl E. Peterson on 3 Nov 2009 14:09 Paul Clement wrote: > On Fri, 30 Oct 2009 12:55:57 -0700, "Karl E. Peterson" <karl(a)exmvps.org> wrote: > > � 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. > > Which most developers do since ActiveX/COM is a significant feature of the > product. And which aspects of ActiveX/COM do you feel would be unavailable without registering MSVBVM50.DLL, hmmm? Any cites you can offer, or just FUD-mongering speculation? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Paul Clement on 3 Nov 2009 14:40 On Tue, 3 Nov 2009 11:09:50 -0800, "Karl E. Peterson" <karl(a)exmvps.org> wrote: � > � 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. � > � > Which most developers do since ActiveX/COM is a significant feature of the � > product. � � And which aspects of ActiveX/COM do you feel would be unavailable without � registering MSVBVM50.DLL, hmmm? Any cites you can offer, or just FUD-mongering � speculation? Think there's some miscommunication here. I was responding to your statement about running a Classic VB app from CD. Since most of these applications implement COM dependencies (as I stated in my post) in most instances some installation and registration is involved first (as you implied in the last sentence of your post regarding "dragging ActiveX stuff into it"). Paul ~~~~ Microsoft MVP (Visual Basic)
From: Nobody on 3 Nov 2009 14:47 "Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:%23F1IlkLXKHA.3720(a)TK2MSFTNGP02.phx.gbl... > I can tell you there's no (runtime-related) problem (that I've yet > encountered!) using VB5 exes on Windows 7 as long as the runtime is either > installed or on the LoadLibrary search path. There are few classes registered that refer to MSVBVM60.DLL. I don't have VB5, but it probably would have the same issues. When I search the registry for "MSVBVM60.DLL", I get few things, one of them is "VBPropertyBag". I searched Object Browser including hidden members, but didn't find it, although I found "PropertyBag" and "PropertyBag_VB5" in Object Browser. I didn't see any of the built-in controls' classes, but I wonder if using something like StdPicture would work. Another interesting entry is for the even log, which I found at the following location: HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application\VBRuntime It refers to MSVBVM60.DLL as the target. I guess this affects App.LogEvent Method. However, see the remarks section in RegisterEventSource() API function which basically says that if an event source is not registered, the Application log is used, but I don't know if LogEvent Method generates an error in this case. Also, as I mentioned in an earlier reply in this thread, when you run an EXE that was generated by VB, OCX files are auto registered that were not registered before. This works in Windows 9x, but in NT, it doesn't work with the limited "Users" group, nor with unelevated admin. Perhaps VB tries to register MSVBVM?0.DLL as well. You can find out by running a VB app as a limited user, or in Vista+, without "Run As Administrator". I do know though that VB6 doesn't register ActiveX DLL files that were created with VB6(I already tried it).
From: Karl E. Peterson on 3 Nov 2009 14:47 Paul Clement wrote: > On Tue, 3 Nov 2009 11:09:50 -0800, "Karl E. Peterson" <karl(a)exmvps.org> wrote: > > � > � 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. > � > > � > Which most developers do since ActiveX/COM is a significant feature of the > � > product. > � > � And which aspects of ActiveX/COM do you feel would be unavailable without > � registering MSVBVM50.DLL, hmmm? Any cites you can offer, or just FUD-mongering > � speculation? > > Think there's some miscommunication here. I was responding to your statement about > running a Classic VB app from CD. Since most of these applications implement COM > dependencies (as I stated in my post) in most instances some installation and > registration is involved first (as you implied in the last sentence of your post > regarding "dragging ActiveX stuff into it"). Okay, right, if you're gonna have external COM dependencies, you're definitely getting into deeper water. I don't know enough about regfree COM to say, but I suspect you'd have to go looking there to run them off a CD. But if you stick to the basics, there's no problem with doing as I said and just treating the runtime as a standard DLL. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 3 Nov 2009 14:54
Nobody wrote: > "Karl E. Peterson" <karl(a)exmvps.org> wrote in message > news:%23F1IlkLXKHA.3720(a)TK2MSFTNGP02.phx.gbl... >> I can tell you there's no (runtime-related) problem (that I've yet >> encountered!) using VB5 exes on Windows 7 as long as the runtime is either >> installed or on the LoadLibrary search path. > > There are few classes registered that refer to MSVBVM60.DLL. I don't have > VB5, but it probably would have the same issues. When I search the registry > for "MSVBVM60.DLL", I get few things, one of them is "VBPropertyBag". I > searched Object Browser including hidden members, but didn't find it, > although I found "PropertyBag" and "PropertyBag_VB5" in Object Browser. I > didn't see any of the built-in controls' classes, but I wonder if using > something like StdPicture would work. > > Another interesting entry is for the even log, which I found at the > following location: > > HKLM\SYSTEM\CurrentControlSet\Services\Eventlog\Application\VBRuntime > > It refers to MSVBVM60.DLL as the target. I guess this affects App.LogEvent > Method. However, see the remarks section in RegisterEventSource() API > function which basically says that if an event source is not registered, the > Application log is used, but I don't know if LogEvent Method generates an > error in this case. > > Also, as I mentioned in an earlier reply in this thread, when you run an EXE > that was generated by VB, OCX files are auto registered that were not > registered before. This works in Windows 9x, but in NT, it doesn't work with > the limited "Users" group, nor with unelevated admin. Perhaps VB tries to > register MSVBVM?0.DLL as well. You can find out by running a VB app as a > limited user, or in Vista+, without "Run As Administrator". I do know though > that VB6 doesn't register ActiveX DLL files that were created with VB6(I > already tried it). Wow! That's some interesting feedback. It'd take a lot of time to develop and run tests on all those situations. I know there are folks who make extensive use of PropertyBags, but I'm not one of them so it's never bit me. Nor do I use LogEvent at all. What do you think of the notion of using regfree COM for externals in this scenario? -- ..NET: It's About Trust! http://vfred.mvps.org |