VB6 userdocument migration

Question

0.00/5 (No votes)

See more:

Apologies, yet another clueless VB6 upgrade question, why won't this thing just die ...

So, I'm half of a pair of developers who inherited a hulking payroll application coded entirely in VB6. The source code weighs in at 50Mb of text files, totaling 900 thousand lines of VB code, plus 110 thousand lines of screen design. This is spread over 290 UserDocuments, 400 modules, 740 classes, and 290 forms. These add up to 360 programs, comprising 290 ActiveX executables, 60 standard executables, 6 DLLs, and 3 controls. Which access and maintain 350 SQL server tables.

Most of the search results I see talk about upgrading a single program. I need to know how an entire system fits together. For example, we have a central executable, which launches those ActiveX executables. I assume we would want to convert the UserDocuments to winforms, compile the old ActiveX executables as standard executables, and change the central executable to launch those?

Given the size of the codebase, it would be nice to be able to run both the ActiveX executables, and the new .NET executables from the same central program. Is this remotely possible? So can either VB6 launch a .NET executable, or VB.NET launch an ActiveX executable?

Hm, if you answered that without breaking a sweat, let's talk about grids ...

Posted 1-Apr-15 0:53am

ThePotty1

Add a Solution

Comments

TheLonelyCoder 16-Apr-15 3:52am

Please specify what you mean with: "Launch an ActiveX executable"?

Definitly it is possible to launch executable files from VB6 executables. And it IS possible to use ActiveX components within a .NET application.

ThePotty1 16-Apr-15 9:02am

As far as I understand, ActiveX exes were designed to allow an executable to run directly in internet explorer. I think we chose to use them because it allowed our central program some late-binding flexibility which we would not have had if all of the daughter programs were DLLs.

On that note, what is the accepted architecture for a large system, where compiling everything into one massive executable is not an option? Should the daughter programs all be DLLs, or standard EXEs?

Obviously you can pass more information back and forth with a DLL, as opposed to just the return code from an EXE. On the other hand, without some sort of late binding, wouldn't you have to code a separate launch routine for each DLL?

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CHill60 · Answer 1 · 2015-04-01T02:21:00

I think these resources might help - I'm thinking you would want to "attack" the system piecemeal...
Using Unmanaged (VB6) Code in .NET[^]
M$ excerpt[^] (NB this is a PDF download)
Other thoughts...
You could always run the executables using Process.Start but I'd be wary of how they might be doing cross-communication (hopefully it's all through the database). We did experiment with named pipes[^] for this and I think eventually used memory mapped files[^]. I left before the whole lot got converted so I don't know what they finished up which after the VB6 had gone.
Shame about the UserDocuments - not many people went down that route, but I would agree to converting them.
Beware - Don't assume that VB.NET is the obvious choice for converting from VB6 just because of the "similarities" - I would personally go for C# (although I suspect you don't have much choice in the matter)

Quote:
let's talk about grids

Nooooooo!
We had no end of bother with grids as there had been heavy use of custom and 3rd party controls. My oppo ended up writing a editable grid-control with variable height rows that could have fore- and back colours configured in C that we took forward, just to keep the UI looking the same(ish).