5
votes

I have a 3rd party legacy app that requires a VB6 Active X EXE library interface. I am looking to update the VB6 Active X EXE library to a currently supported language. As the legacy host application is from a 3rd party I do not have the ability to change the host API to use an interface other than ActiveX EXE. Is there any currently supported Microsoft language i.e., x86 C++, C++/CLI, C# or VB.NET that can create the equivalent of an ActiveX EXE interface?

I suspect the answer is no but am looking for a definitive response saying so. That any legacy host application using ActiveX EXE library must be itself be modified to allow the use of supported languages and tools. Basically confirming that effectively ActiveX EXE is now an unsupported API interface.

I've already looked at this similar question and from it one could deduce that the answer is no but there is no definitive response. I've also looked at this Microsoft Tutorial and from what I can tell it talks about updating the host application which isn't an option in this case. The tutorial talks about switching to an ActiveX DLL but my understanding is that this would require a change to the 3rd party host application. Again that is not an option in my case. I need something that looks like an ActiveX EXE library to the host.

1
Why does it need to be "currently supported"? Amazingly enough VB6 still works so why cant you use that?Ňɏssa Pøngjǣrdenlarp
Because it is already a difficult environment to work in and going forward I only expect it to get worse. Currently I have been unable to get VB6 to install on Win10 (and I've made multiple attempts on multiple systems) so I am forced to develop on Win7. Then there are the little annoyances like mouse wheel doesn't work and there is no facility for pre or post build events. And then there are other interfaces we'd like to use that require .NET environment. And then there's the issue that VB6 isn't fully object oriented.JonN
You can make a VB6 ActiveX Exe wrapper, and reference a COM Visible .Net assembly where you will do most of your development.djv
JonN: since you mentioned some specific niggles: there are fixes for the mouse wheel and you can build VB6 projects from the command-line which might allow pre/post build processing. However I fully understand (and share) a desire to use .NET for your development work.MarkJ
@JonN install the VBAdvance plugin to the VB6 IDE for the auto-code-reload feature.StayOnTarget

1 Answers

1
votes

If you are sure that an ActiveX Exe is required, have you considered just using VB6 to create the that as a thin shim and then have it delegate all implementation to a .NET assembly? You probably would never need to recompile the Exe again, unless the 3rd party vendor is still expanding their interface.

If you post some more information about the VB6 Active X EXE library interface, I might be able to refine this solution with specific code samples. Presumably your Active X Exe must implement a provided interface?