Hi. First sorry for my bad english.

        I thought that port my application (made with VB 4.0 32, third-party
controls, DAO 3.0, communications, etc..) to VB 5.0 consists in open the
project and re-compile it to native code, but some features doesnt work
very well (only the VB 5.0 version :) ). I saw different news about
problems with the new version of the common controls that I used (Comctl32,
Comdlg32, Dblist32). I recovered the VB 4.0 version of these controls, I
ran "Regsvr32.exe" and "Regocx32.exe" in order to registry them, and I made
an executable file (native code). All was fine (loadig and compiling) , but
while was writing the executable file VB5 spat out a GPF in Mfc40.dll, and
the exe file never was built :((.

        In short, I have a VB4 application that works fine,
                the same application compiled in VB5 that works bad ,
                different version of (only) those files and
                a GPF in Mfc40.dll when I try to compile it with the previous controls.

        How can I register the VB4 Common Controls in order to compile my
application with VB5 and it works fine? or
        Is there some patch that fix this problem? or
        Is there some "compatibility control" like DAOs 2.5/3.0 or something like
that? or
        I must un-install VB5 and re-install VB4 and wait for a better chance?

        Thanks in advance..

Sylvester the Wild Cat!!
______________________________________________________________
    ______

  /\/_/\_\/   Software Engineer
  \/\/\/\_\   Visual Tools S.A.
   \/\/\/_/   Xaudaro, 13 bis 2o planta  Tel: +34 1 729 48 44  
    \/_/      E-28034 Madrid (SPAIN)     Fax: +34 1 358 52 36
______________________________________________________________

Angel,
I have encountered this problem too.  The only solution I have found so far
is this:
* Uninstall VB5
* Install VB4 to a different folder (like C:\VB4)... just a minimal install
should be fine
* Now Install VB5, but do NOT install into the VB4 folder... give it it's
own folder
After rebooting, all should be well and you can now use the COMCTL32
controls without error. I admit it's an ugly solution... but at least it
works.

    Mark Robbins