none
Compile error in hidden module: frmMain RRS feed

  • Question

  • I have an application written using Visual Basic for Applications version 6.5. The application works fine on Windows XP but when I try to run it on Windows 7(32bit) I get the following message:

    "Compile error in hidden module: frmMain. This error commonly occurs when code is incompatible with the version, platform, or architecture of this application. Click "Help" for information on how to correct this error."

    The Visual Basic code is executed within an Windows Excel 2010 spreadsheet. There are also supporting dlls written in C++.

    How can I get this application to run within a 32 bit Windows 7 environment?

    Tuesday, October 16, 2012 10:30 PM

All replies

  • Hi,

    maybe you have missing components, please check in the VBE under Tools->Reference if there are missing components. If you will see MISSING try to uncheck the MISSING checkboxes save the file and then recheck the file.

    


    Guy Zommer

    Wednesday, October 17, 2012 4:58 AM
  • I tried your suggestion and I did not find any missing components.
    Wednesday, October 17, 2012 7:00 PM
  • What controls are you use.

    You can have a problem with common controls.

    Find a mscomctl.ocx and mscomct2.ocx and write a versions from file properties.


    Oskar Shon, Office System MVP

    Press if Helpful; Answer when a problem solved

    Wednesday, October 17, 2012 7:24 PM
    Answerer
  • Do you have access to the code? Does the code use API calls?

    Felipe Costa Gualberto - http://www.ambienteoffice.com.br

    Wednesday, October 17, 2012 10:05 PM
  • Taurus64 are you alive?

    you can upgrade libraries to newest one:

    mscomctl.ocx http://support.microsoft.com/kb/896559

    mscomct2.ocx http://support.microsoft.com/kb/297381

    pkgmgr /ip /m:<filename>.cab /quiet

    From regular install CC (take look at minors):

    and CC2


    Oskar Shon, Office System MVP

    Press if Helpful; Answer when a problem solved

    Friday, October 19, 2012 8:25 AM
    Answerer
  • Just a quick heads up, probably best not to download the files referred to
    in these links (kb 896559 & 297381). These versions are very out of date,
    unlikely they will work in newer systems or even XP after 2009 and might
    cause problems.
     
    However it is possible that thee problem is due to a very recent update of
    those controls and can affects Win7, and might need to roll back to the
    previous version.
     
    Taurus64, establish if that's the problem. In a brand new project try
    setting a reference to any non standard aX Office controls you are using, eg
    mscomctl.ocx. Simplest is to try and add to a VBA userform in the
    problematic Win7 machine. If it fails and the  control exists in file check
    it's version and date and post back the details.
     
    Peter Thornton
     
    Saturday, October 20, 2012 8:13 PM
    Moderator
  • @Peter, did you find newest one?

    I was looking any MSI or EXE setup - without good result. I find something, but in VB6 Packet - no use with VBA. Automatic UPG is not solved problem on every machines. I'm chcecking every single one.

    Even my CreateInstall gives to me controls from 2007


    Oskar Shon, Office System MVP

    Press if Helpful; Answer when a problem solved

    Monday, October 22, 2012 11:17 AM
    Answerer
  • The VB6 runtime has been packaged with Windows (IIRC) since Win98SE. Many of
    its dll's & ocx's (eg mscomctl.ocx) should automatically get updated and
    already be on all systems incl Win7. It is extremely likely that newer
    versions of the relevant controls already exist on the system than referred
    to in those links. Whether or not they are correctly installed is a
    different matter!
     
     
    The recent August resulted in several reports of problems with the "common
    controls", I tested and replicated the problem.
     
    For me the solution was to roll back - IOW it was the latest update that
    caused the problems. Until the OP follows up to my post we don't know if
    that's likely to be his problem, however this is how I went about restoring
    the previous version in my Win7 (wasn't quite as straightforward as it
    should have been)
     
     
    Peter Thornton
        <VBATools [MVP]> wrote in message
    news:70c428c5-85bb-4d92-8cfe-10aa700719f8@communitybridge.codeplex.com...
    > @Peter, did you find newest one?
    >
    > I was looking any MSI or EXE setup - without good result. I find
    > something, but in VB6 Packet - no use with VBA. Automatic UPG is not
    > solved problem on every machines. I'm chcecking every single one.
    >
    > Even my CreateInstall gives to me controls from 2007
    >
    >
    >
    > --------------------------------------------------------------------------------
    >
    > Oskar Shon, Office System MVP
    >
    > Press  if Helpful; Answer when a problem solved
    >
    >
     
     
    Monday, October 22, 2012 1:18 PM
    Moderator
  • Hello Peter:

    I have an XP machine and a Windows 7 machine. Both have the recent version of MSCOMMCTL.OCX (date: 06/06/2012). The Win XP machine runs my application without a problem whereas the Win 7 machine has the problems described above. Rolling back to an earlier version may not work becaus again the same version of MSCOMMCTL.OCX resides on both machines.

    Taurus64

    Monday, October 22, 2012 8:02 PM
  • Not sure but I wouldn't expect a problem in this particular case if your XP
    & Win7 are running different versions. One thing though, you can probably
    remove the reference (tools, ref's).
    "Microsoft Windows Common Controls 6.0 (SP6)"
     
    What typically happens is the reference gets added when the control is added
    to the form. However it's only needed if your code declares an explicit
    object reference to the control. But test.
     
    I had another look at my Win7 and it seems subsequent updates have
    reinstated the latest version, also dated 06-Jun-2012. However I think
    better to refer by version because the same ocx might be dated differently
    on different systems, it's -
     Mscomctl.ocx 6.1.98.34
     
    Curiously this now appears to be working without a problem (it definitely
    wasn't a few weeks ago). I noticed though that control names (in the
    Toolbox) were named "unknown". I removed (say Treeview) added it back and
    its name was then correctly listed.
     
    This makes me suspect some other subsequent Win7 update now allows things to
    work with Mscomctl.ocx 6.1.98.34.
     
    My XP has an older version which I recall was required to fix a particular
    security issue (older versions will almost certainly not work in XP which
    was the point of my original "heads up")
     Mscomctl.ocx 6.01.9816  2009/03/24  in my XP
     
    I'm curious as to why your XP has the newer version, my XP gets regularly
    updated.
     
    FWIW I can confirm the GUID is the same in both above versions,
    {831FDD16-0C5C-11D2-A9FC-0000F8754DA1}
     
    All the above is just a series of observations and doesn't address how to
    fix your particular issue. I can only suggest in your Win7 try the following
     
    - Remove any references (as described above)
     
    - Try rolling back a previous version on your Win7, eg I found this
     Mscomctl.ocx  6.1.98.33
     
    I note what you say about having the new version on your XP but I don't
    think that'd cause a problem. Curiosity - did you or some non directly
    windows update install that new version on your XP.
     
    Peter Thornton
      
    <Taurus64> wrote in message
    news:aa5ada53-155c-4459-96cd-a0d2f9f4d225@communitybridge.codeplex.com...
    > Hello Peter:
    >
    > I have an XP machine and a Windows 7 machine. Both have the recent version
    > of MSCOMMCTL.OCX (date: 06/06/2012). The Win XP machine runs my
    > application without a problem whereas the Win 7 machine has the problems
    > described above. Rolling back to an earlier version may not work becaus
    > again the same version of MSCOMMCTL.OCX resides on both machines.
    >
    > Taurus64
    >
     
     
    Tuesday, October 23, 2012 9:00 AM
    Moderator