I recently installed some software that replaced a couple of my VB4 OCXs
with VB5 versions of them. Under Custom Controls, MaskEdBox now says
it's a VB5 (SP2) control, along with a couple of other controls.

I opened a test project and tried to use the controls and everything
seemed okay... IOW, I didn't get the "You do not have a license to use
this in the design environment" error. There seems to be a few new
properties to some of the controls, but the test project didn't have any
trouble. I did not, however, create a distribution diskette to see if
they would install properly on another machine though.

What should I do here? If I replace them with my VB4 versions, then the
software I installed that uses them will bomb out... but if I can't
distribute my app with those controls, then I have no choice but to go
back (and I'll live w/o the app that installed the new controls). The
app created a backup dir of the files it replaced... the VB4 (and other
system) files that were replaced are:

COMCTL32.OCX
COMDLG32.OCX
DAO350.DLL
MFCANS32.DLL
MSMASK32.OCX
MSVBVM50.DLL
MSVCRT.DLL
MSVCRT20.DLL
MSVCRT.40.DLL
OLEPRO32.DLL
RICHTX32.OCX
VBAJET32.DLL

Anyone else run into this? If I can legally use and distribute these
controls, can they still use VB4 version DLLs or will the Setup Wizard
try to install the VB5 DLLs and then fail because I don't have
distribution rights on all the above files?

On a related note... I have VB4/Jet3.0 on my system and also have Access
97/Jet3.5 on my system (note that some Jet DLLs were replaced above).
I've used Access to design my database and VB4 for the front end. So
far, VB4 using the Jet 3.0 engine hasn't had any trouble with the db
that I've also worked on in Access - is there anything I have to look
out for before distributing it?

I'd upgrade to VB5 to avoid this mess, but that's not possible right now
(I first need to upgrade my 486 to a Pentium and add more ram).

Suggestions anyone? Thanks, Michele
--
Change 'nospam' to 'chaos to reply via email.

From a personal viewpoint, you should experience no problems *running* older VB4-32 apps
with VB5-installed controls.  But you can no longer use VB4 to create the exe because, as
you pointed out, the support files (OCX, OLE and the "lesser-known" support files) are now
VB5-flavour.  IMHO VB5 was not meant to be an adjunct to VB4-32, but rather a replacement.
I'm sure MS intended this as well. I have serious doubts as to whether you actually could
go backwards by simply using the backed-up controls.

If I were me, which I am, I'd distribute the apps as VB5, which I do.  :-)

Randy Birch, MVP Visual Basic
VBnet, The Visual Basic Developers Resource Centre
http://home.sprynet.com/sprynet/rasanen/vbnet/default.htm

:I recently installed some software that replaced a couple of my VB4 OCXs
:with VB5 versions of them. Under Custom Controls, MaskEdBox now says
:it's a VB5 (SP2) control, along with a couple of other controls.
:
:I opened a test project and tried to use the controls and everything
:seemed okay... IOW, I didn't get the "You do not have a license to use
:this in the design environment" error. There seems to be a few new
:properties to some of the controls, but the test project didn't have any
:trouble. I did not, however, create a distribution diskette to see if
:they would install properly on another machine though.
:
:What should I do here? If I replace them with my VB4 versions, then the
:software I installed that uses them will bomb out... but if I can't
:distribute my app with those controls, then I have no choice but to go
:back (and I'll live w/o the app that installed the new controls). The
:app created a backup dir of the files it replaced... the VB4 (and other
:system) files that were replaced are:
:
:COMCTL32.OCX
:COMDLG32.OCX
:DAO350.DLL
:MFCANS32.DLL
:MSMASK32.OCX
:MSVBVM50.DLL
:MSVCRT.DLL
:MSVCRT20.DLL
:MSVCRT.40.DLL
:OLEPRO32.DLL
:RICHTX32.OCX
:VBAJET32.DLL
:
:Anyone else run into this? If I can legally use and distribute these
:controls, can they still use VB4 version DLLs or will the Setup Wizard
:try to install the VB5 DLLs and then fail because I don't have
:distribution rights on all the above files?
:
:On a related note... I have VB4/Jet3.0 on my system and also have Access
:97/Jet3.5 on my system (note that some Jet DLLs were replaced above).
:I've used Access to design my database and VB4 for the front end. So
:far, VB4 using the Jet 3.0 engine hasn't had any trouble with the db
:that I've also worked on in Access - is there anything I have to look
:out for before distributing it?
:
:I'd upgrade to VB5 to avoid this mess, but that's not possible right now
:(I first need to upgrade my 486 to a Pentium and add more ram).
:
:Suggestions anyone? Thanks, Michele
:--
:Change 'nospam' to 'chaos to reply via email.
:
:

Well, I'd love to distribute VB5 apps, but I don't have the VB5
compiler! <grin> If my programs still compile in the VB4 compiler, then
I'd most likely end up with a VB4 app that uses a few v5 DLLs, and I'd
need to distribute the v5 DLLs instead of the v4 DLLs that came with
VB4a.

As to going back to the v4 files that were replaced, that shouldn't be
too much of a problem... the app that installed the VB5 files created a
Backup dir of the files it overwrote - if it has a good install program,
it should un-install the VB5 files and restore the VB4 ones - if not, I
still have my VB4 cd and can reinstall.

But... if it compiles and distributes with no problems, I may leave it
as it is. My question was, has anyone else had this situation and _did_
the VB4 apps compile and distribute (via Setup Wizard) with no problems?
I've already run into the OLE files creating havoc (since IE4 and other
apps have already replaced them), but I can work around that... I was
wondering of any other problems I might run into... will I need the VB4
runtime _and_ the VB5 runtime, even if I don't use any of the new
properties in the OCX's, or just the VB4 runtime, or just the VB5
runtime?

Thanks again, Michele
Change 'nospam' to 'chaos to reply via email.