BASIC Developer & Support Resources > VB (5/6/CE) Classic

VB6 not dead

<< < (3/13) > >>

One of the first things I learned when using VB was to ensure that the executable was packaged with whichever .DLL, .OCX and resource files it required locally, i.e. in/below the executable directory.

That even included a copy of shell32.dll for any system icons that may be referenced - surprisingly, that fixed a couple of installation problems when compiling on Win 98 and installing on NT4, back in the day.

While it may be necessary to access registry settings, I found that using program.ini for program settings was an absolute godsend, and avoiding a lot of mucking about with installers - my installs were all done with batch files and a configuration utility. Clunky, slow and very reliable.

Your VB6 app is required to regsrv32 and unregister the custom OCX (s) it uses. The VBCCR13.OCX I'm using does that for me automatically.

Mike Lobanovsky:
You can link your VB6 Classic/VB6 CE custom controls into your VB6 executables, in which case you won't have to register anything at all on the target machine if your application has no use of external COM by design or intended purpose. Regardless of VB6's own engine being a transparent 100% COM solution. :)


--- Quote ---VB6's own engine being a transparent 100% COM solution.

--- End quote ---

I feel this is the reason developers have been able to  keep VB6 relevant without source.

Mike Lobanovsky:
Nah, they usually tailor it to their needs via its MSVBVM60.DLL's undocumented API and/or vtable patches to redirect program flow to custom callbacks and expose the otherwise unavailable pointers to VB6 intrinsic objects (essentially COM variants).


[0] Message Index

[#] Next page

[*] Previous page

Go to full version