Step #2 : Purchase and Install Software
Obviously you will need to install Visual Basic 4. I had no problems installing both the 16bit and 32bit programs in the same directory. You will most likly want to convert your VBX's to OCX equivalents, and I use the word "equivalent" loosly. More on that to follow. Install each of the OCX products after you installed VB4 since they must get properly registered in the Microsoft Registry. When you install VB4 you will find a program called REGCLEAN.EXE in the WINDOWS directory. I run this often and am amazed at how many problems it constantly has to fix. Not sure if 3rd party vendor install problems are causing this, but I would keep that utility handy.

Step #3 : Fix Object Server Not Recognized
Do you see "Object Server Not Recognized" when you right mouse click on your tool menu and try to bring up the controls list. I get this often after registering 3rd Party Control and from surveying user group E-mail forums I don't think I am alone. The best way I have found to get rid of this is the following:

• Copy all OCX's from /WIN95/SYSTEM to another directory.
• Delete all *.OCX and *.OCA files in your systems directory.
• Reboot your machine and run REGCLEAN 3.0. Be sure to use Version 3.0 which can be downloaded for Microsoft and is on the recent Visual Basic 4.0a CD-ROM.
• Copy all *.OCX files back into your windows system directory.
• Register each one of them by using the REGOCX16.EXE and REGOCX32.EXE executables.

Step #4 : Fix OCX Naming
I would recommend that you then start VB4 and start a new project. Then using the Control Manager load every control you have registered into a dummy project and save it. This will provide all the proper control names, identification numbers and version information. Take that info from your .VBP file (formerly .MAK) and insert it in the VB.INI file in your Windows directory under the conversion sections. This will be obvious when you open up and look at the VB.INI file, make sure you use the same format. I noticed several of my controls did not have the proper version info in the VB.INI file before I did this. It may not matter but it doesn't hurt to be careful.

Step #5 : Backup VB3 VBX Project
Enough said...

Step #6 : Go for it !
Do you feel lucky. In theory, according to Microsoft, you can now just load your VB3 projects into VB4 and have the VBX's convert to OCX's. Depending on what controls you used and what use of API calls your code has this may actually work. But there are many problems that can occur so don't bet on it. The biggest problem I had was that VB4 environment would actually lock up with GPF's if the OCX's were not identical to the VBX's for all the naming conventions. If you can do this and not get any .LOG files, a GPF that locks up your system, and a project that loads, converts VBX's to OCX's and compiles without errors, your done. Glad to hear it.

Step #7 : Convert Project to VB4 Only !
This problems can occur for many reasons I recommend that you first attempt to load your project into VB4 without converting to OCX's. This is not necessarily straight forward so we can't assume this will work without a hitch. Truegrid users may need to download the updated VBX for VB4. Apex (authors of Truegrid) have a different VBX for VB3 and VB4.

Step #8 : Determine if OCX's Available
Not all VBX's were converted to OCX's thus you may need to continue using some of your VBX's. MicroHelp has announced that they are no longer going to include 16bit OCX's with there products. And other VBX's did not make the conversion to 16 or 32 bit OCX's, such as: Crescents CSGROUP and QPSCROLL, and Microsofts PENCNTRL, MSOLE2, OLECLIEN. Project still may convert by using old VBX's but you should be aware of this.

Step #9 : Try again to load with OCX's
First goal is to get your project to load without creating any .LOG files. Even though you make it past this step you may still get a GPF in the process later on, but lets address these LOG files first. You are getting them most likly (assuming your VB4 code with VBX's worked) since the OCX vendor changed the control name when they went from a VBX to OCX. This is easily fixed by doing a text search and replace in your FORM files with the new name. Some examples of name changes were Crescents QPLIST to CSLIST16, and CSCLOCK to CSCLOK16. Also Apex TrueGrid changed from TRUEGRID to TDBG16.

Step #10 : Apex TrueGrid Product
One of the most difficult pains in conversion is with the popular Apex Truegrid. To make matters worse there is a mirage of different products distributed by Apex to really confuse the matters. The end result though is that major changes were made from the VBX to the OCX thus you will probably be better off just deleting these controls from your forms inorder to get them converted to VB4. Save the code though since some of it may be able to be inserted later. To help a bit though here is a list of the different Apex Controls released over the past few years. Inaddition each of these have different release version numbers, some are 1.x, 2.x, 4.x and 5.x.

1. TrueGrid (TRUEGRID)           VBX  Standard Edition
2. TrueGrid Pro (TRUEGRID)       VBX  Purchased Product
3. TrueGrid Pro Fix (TG_VB4)     VBX  VB4 Fix Not VB3
4. DBGrid (DBGRID16,DBGRID32)    OCX  Free With VB4 Pro
5. TrueDBGrid Strd (TDBGS16/32)  OCX  Free Upgrade DBGrid
6. TrueDBGrid (TDBG16, TDBG32)   OCX  Purchased Product
7. TrueDBGrid Pro (TDBG16/32)    OCX  Purchased Product

Step #11 : Take Care of GPF Errors
Well by now hopefully we are least not getting any .LOG file errors though you may be getting GPF errors prior to getting control in the development environment. This was my biggest pain. The only way to attack this problem is to remove all of the .FRM files from your .MAK file and try to load the project again. Then repeat this process by adding a few forms back each time. I did this and found Crescents CSOPT and CSPICTUR controls giving GPF errors. Once you find a specific form causing problems try to find a control in there which is unique to that form as compared to other forms that load properly. I simply removed these controls manually from those FRM files, loaded the entire project then re-inserted them into the forms in the development environment. This one is a real pain and Microsoft only confirmed to me that this has happened often but there is really no better way to address this issue. It is slow and tetious.

Step #12 : Run Project in Development
So you have made it into the VB4 development environment now with a your project converted to OCX's. Hopefully, you didn't have to manually delete too much code. Trying to run your project in Development environment will bring up all the errors with API definitions that changed. Many of the API calls changed from Integer to Long Integer. You may of caught many of these when you loaded your project in with the VBX's however. Also be sure to change all GLOBAL declarations to PUBLIC declarations.

Step #13 : Compile Project in Development
A whole new series of errors can occur even though you could run the project in the development environment once you try to compile it. Some of them may be event calls were renamed from the VBX to OCX controls, which was evident in Crescents CSFORM control. Create a new form and load a dummy event for each one on that form. Look at the changes and insert manually into your code the proper Sub declaration lines.

Step #14 : Congratulations your Done
Getting the project loaded and to compile without an error can be a real pain. And I am not sure as too how much of my code will need to be re-written yet but at least you have some project up and running in the VB4 development environment with the latest version of your 3rd party controls. Nice job...