VB6 Activex Exe file causes Run-time error 429

I would suggest that where you are going wrong is attempting to use MSComm in a VB6 app.  The control has always been buggy and not all the member functions operate the way they are documented.

Anyone I ever knew that needed a "professional" program to utilize the COM ports has skipped the MSComm control and learned how to use the Windows API to control the COM port (which of course requires many more steps than it does with MSComm.

I never did any professional work with MSComm myself (so I don't have an example of how to use the API).  But I have programmed a home project with MSComm and found that at a minimum, the COM did not behave reliably (requiring many reboots to get the COM ports reset).


Otherwise, it is most likely that you are getting the dreaded "can't create object" because either a control is missing from the machine you're trying to run the control on, OR the version number of the control you are trying to run against is different than the version you compiled against (frequently known as DLL hell).  In the case where you are trying to run the project from the debugger and it is still failing, you would need to verify that all controls referenced by your project are on the same version number on both machines.  Actually, if the problem is with a version number of one of the controls you are referencing directly (as opposed to something that is created dynamically or is a dependancy of your dependancy) the project usually fails to properly open until you get the version numbers in sync.  I've personally had a devil of a time trying to make that happen when it turns out that you built the project using an earlier version of a control than the version on the machine you are trying to run on.  In which case, you've got to either update the control on your developement machine, or compeletely delete all traces of it (including in the registry) on the target machine so that your installer will install the older version of the control.  When the installer sees a later version of a control, it won't overwrite the newer version (under the assumption the newer one is going to be compatable).

Thanks for that feedback. I have up until now had success with the MSComm control but as it happens I no longer need it for this project so I removed it and recomplied the activex exe and the app exe so the only control was mswinsck.
The same error occurred...error 429!
on this particluar pc, I ran a vb6 install but selected only the activex component of the install. Once the install was complete, the app works fine!
I am not sure what part of the vb6 activex install fixed it but it did! Now I have to discover what did it so I can create the same fix on further PC's!
Any help with this would be great!

Further to my last response....after I installed the ActiveX component only of the VB6 install, I proceeded o uninstall it. Once complete, my app still works fine!
I ran a check over the 2 version of the registry both bfore and after VB6 install & uninstall and nothing stands out as being relevant!
Unless anyone is able to help I will just have to run through this process each time.

If your projects only dependency is mswinsck, then I would suggest doing a full search in your computer's registry (the computer that is getting the error) and delete every registry entry that includes "MSWINSCK.OCX".  Then try rerunning your install (which I assume includes a copy of MSWINSCK,OCX).

BTW, the worst case I've faced similar to what you are facing right now is when the target machine had a slightly different version number of a control than my compile machine did, even though the GUID was identical.

For example, if you look at VBP in Notepad, you should see a line that looks something like this:
Object={248DD890-BB45-11CF-9ABC-0080C7E7B78D}#1.0#0; MSWINSCK.OCX

I had a situation (with a different control) where that version number (#1.0#) was something like #1.1# on the target machine.  When the install would run, trying to install #1.0#, it would see the control already exists, and that the control on the target machine was a higher version number, so it wouldn't replace the control.  And for some reason, the 1.0 version in the project was incompatable with the 1.1 version on the target machine even through the GUID was the same for both controls.

It was just what worked even though a clumsy solution!