Asp Forum - Your thoughts on converting parts of a VB6 app to C++

Tony Toews

9/14/2011 3:35:00 AM

Folks

Maybe my thoughts in the following posting aren't very coherent.
<smile> I'm just doing a bunch of brain storming here.

Office 15 has been ported to the ARM CPU which won't support the VB6
runtime DLL at all. And my utility is meant for MS Access so I need
to consider my options.

(Of course I'm not sure how many folks are going to want to run Access
on the ARM CPU form factor but ...)

My VB6 Auto FE Updater app really has two parts. The GUI for the
developer who is setting up the utility. Then there's the code that
does the work.

So I'm thinking I'll leave the GUI in VB6, for now, and convert the
code that does the work into C++ but in two stages.

The modules basically only call one form that displays an error
message along with various optional command buttons and such.

But I don't know if DLLs can have forms? Maybe not? Shows how
little I know about VB6 DLLs.

1) convert all my VB6 modules so they work as VB6 DLLs and call it
from VB6. This way I know I have the DLL stuff working smoothly. And
maybe this is relatively easy to do. I don't know.

2) Convert the VB6 modules to C++. Preferably using a tool that will
do most of the work. Preferably 95%+ but yeah, right.

Huge PITA in doing the conversion of course. Bugs, etc, etc.

I've never worked with C++ The code in the modules is about 11K
lines of code which includes the 2,600 lines of code in the API
module.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

25 Answers

ralph

9/14/2011 8:56:00 AM

On Tue, 13 Sep 2011 21:34:54 -0600, Tony Toews
<ttoews@telusplanet.net> wrote:

>Folks
>
>Maybe my thoughts in the following posting aren't very coherent.
><smile> I'm just doing a bunch of brain storming here.
>
>Office 15 has been ported to the ARM CPU which won't support the VB6
>runtime DLL at all. And my utility is meant for MS Access so I need
>to consider my options.
>
>(Of course I'm not sure how many folks are going to want to run Access
>on the ARM CPU form factor but ...)
>
>My VB6 Auto FE Updater app really has two parts. The GUI for the
>developer who is setting up the utility. Then there's the code that
>does the work.
>
>So I'm thinking I'll leave the GUI in VB6, for now, and convert the
>code that does the work into C++ but in two stages.
>
>The modules basically only call one form that displays an error
>message along with various optional command buttons and such.
>
>But I don't know if DLLs can have forms? Maybe not? Shows how
>little I know about VB6 DLLs.
>
>1) convert all my VB6 modules so they work as VB6 DLLs and call it
>from VB6. This way I know I have the DLL stuff working smoothly. And
>maybe this is relatively easy to do. I don't know.
>

Pretty easy.

>
>2) Convert the VB6 modules to C++. Preferably using a tool that will
>do most of the work. Preferably 95%+ but yeah, right.
>
>Huge PITA in doing the conversion of course. Bugs, etc, etc.
>

Don't even go there and here is why in your own words ...

>I've never worked with C++ The code in the modules is about 11K
>lines of code which includes the 2,600 lines of code in the API
>module.
>

Conversion is a non-trival exercise even for those very familar with
both sides. Any 'automatic' tool would only leave you with 11k of
goobly-gook. You're better off to do it manually and learn as you go.
It will go faster than you think and your C++ skills will grow with
you. If the "GUI" is that simple then consider writing simple dialogs
in C++.

In other words - Acts 27:40.
However, hopefully avoiding Acts 27:41 <bg>

-ralph

Mayayana

9/14/2011 12:35:00 PM

| But I don't know if DLLs can have forms?

Yes, they can....
But they can only show modal....
But you can get around that with ShowWindow...
But then tabbing to set focus breaks so you
have to use a workaround...

Other than that, I don't know of any gotchas.

(nobody)

9/14/2011 5:13:00 PM

"Tony Toews" <ttoews@telusplanet.net> wrote in message
news:8760779gsjksn0ar4m6fu73eq2b6lffog3@4ax.com...
> So I'm thinking I'll leave the GUI in VB6, for now, and convert the
> code that does the work into C++ but in two stages.

What I recommend is isolate the GUI code from the non-GUI code. For example,
in a Click event, put the code into a subroutine and that subroutine should
not access any GUI elements directly. If it needs to check if a particular
CheckBox is enabled for example, then you should pass it to that subroutine
as a Boolean variable. That way the GUI code is much smaller and can be
discarded or replaced easily to work with another platform. If it helps, you
can add ui/UI before or after a routine name so you know it deals with
mostly GUI code. I have some routines like that, and they add list items or
sort a ListView, so there is mostly GUI code in them, so later I can discard
that routine without affecting other logic in the software.

> But I don't know if DLLs can have forms? Maybe not? Shows how
> little I know about VB6 DLLs.
>
> 1) convert all my VB6 modules so they work as VB6 DLLs and call it
> from VB6. This way I know I have the DLL stuff working smoothly. And
> maybe this is relatively easy to do. I don't know.

Yes, you can have forms in any ActiveX projects, but there is one getcha in
making DLL/OCX and try to talk to them from VBA(Not VB6). Office x64 can't
load 32-Bit DLL's because its own process is 64-Bit, but there is a
workaround for that, which involves either turning the project into ActiveX
EXE, so it runs on its own process(VBA in Office 32/64 can always talk to
ActiveX EXE's), or (more work) call the COM functions directly so the
ActiveX DLL is run out of process by using DLLHOST.EXE as a surrogate
process.

GS

9/14/2011 5:28:00 PM

Nobody formulated on Wednesday :
> Yes, you can have forms in any ActiveX projects, but there is one getcha in
> making DLL/OCX and try to talk to them from VBA(Not VB6). Office x64 can't
> load 32-Bit DLL's because its own process is 64-Bit, but there is a
> workaround for that, which involves either turning the project into ActiveX
> EXE, so it runs on its own process(VBA in Office 32/64 can always talk to
> ActiveX EXE's), or (more work) call the COM functions directly so the ActiveX
> DLL is run out of process by using DLLHOST.EXE as a surrogate process.

I'd be very interested in learning more about this! Can you direct me
to any resources?

--
Garry

Free usenet access at http://www.eternal-sep...
ClassicVB Users Regroup! comp.lang.basic.visual.misc

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

(nobody)

9/14/2011 6:55:00 PM

"GS" <gesansom@netscape.net> wrote in message
news:j4qo9r$30kg$1@adenine.netfront.net...
> Nobody formulated on Wednesday :
>> Yes, you can have forms in any ActiveX projects, but there is one getcha
>> in making DLL/OCX and try to talk to them from VBA(Not VB6). Office x64
>> can't load 32-Bit DLL's because its own process is 64-Bit, but there is a
>> workaround for that, which involves either turning the project into
>> ActiveX EXE, so it runs on its own process(VBA in Office 32/64 can always
>> talk to ActiveX EXE's), or (more work) call the COM functions directly so
>> the ActiveX DLL is run out of process by using DLLHOST.EXE as a surrogate
>> process.
>
> I'd be very interested in learning more about this! Can you direct me to
> any resources?

Programming Guide for 64-bit Windows:
http://msdn.microsoft.com/en-us/library/bb427430%28v=VS....

Running 32-bit Applications (From the link above):
http://msdn.microsoft.com/en-us/library/aa384249%28v=VS....

Quote: "The system provides interoperability across the 32/64 boundary for
scenarios such as cut and paste and COM. However, 32-bit processes cannot
load 64-bit DLLs for execution, and 64-bit processes cannot load 32-bit DLLs
for execution."

Process Interoperability (From the first link above):
http://msdn.microsoft.com/en-us/library/aa384231%28v=VS....

Quote: "On 64-bit Windows, an out-of-process 32-bit COM server can
communicate with a 64-bit client, and an out-of-process 64-bit COM server
can communicate with a 32-bit client."

Interprocess Communication Between 32-bit and 64-bit Applications (From the
first link above):
http://msdn.microsoft.com/en-us/library/aa384203%28v=VS....

However, VB's CreateObject() function if used to load a 64-Bit AxDLL would
fail because of the flags that it uses when it calls CoCreateInstance(). It
would succeed if the Ax is a 64-Bit EXE. To make VB run a 64-Bit Ax DLL, you
need to do two things:

1 - Call CoCreateInstance() while specifying the flag CLSCTX_LOCAL_SERVER by
itself without specifying any of the other flags. MSKB Q180217 shows a
function called CreateObjectEx(). This is not an API function, but a
function implemented inside that article. Inside it you need to replace this
line:

Context = CLSCTX_SERVER

With this line:

Context = CLSCTX_LOCAL_SERVER

2 - Add DllSurrogate entry in the registry for that COM component:

DllSurrogate:
http://msdn.microsoft.com/en-us/library/ms691260%28v=VS....

Despite the fact that any 32/64 process can talk to COM 32/64 component
using the above method, Microsoft chose not to implement it that way in
either Office, nor Windows Shell(Explorer), but they have implemented it for
IIS server(Web Server). See these links for more details:

Some Windows Explorer extensions and some Control Panel items are not
displayed on computers that are running an x64-based version of Windows
http://support.microsoft.com...

Compatibility Between the 32-bit and 64-bit Versions of Office 2010(See
ActiveX Control and COM Add-in Compatibility link)
http://msdn.microsoft.com/en-us/library/ee691831%28office....

Tony Toews

9/14/2011 8:01:00 PM

On Wed, 14 Sep 2011 03:56:18 -0500, ralph <nt_consulting64@yahoo.net>
wrote:

>>2) Convert the VB6 modules to C++. Preferably using a tool that will
>>do most of the work. Preferably 95%+ but yeah, right.
>>
>>Huge PITA in doing the conversion of course. Bugs, etc, etc.
>>
>
>Don't even go there and here is why in your own words ...
>
>>I've never worked with C++ The code in the modules is about 11K
>>lines of code which includes the 2,600 lines of code in the API
>>module.
>>
>
>Conversion is a non-trival exercise even for those very familar with
>both sides. Any 'automatic' tool would only leave you with 11k of
>goobly-gook. You're better off to do it manually and learn as you go.
>It will go faster than you think and your C++ skills will grow with
>you. If the "GUI" is that simple then consider writing simple dialogs
>in C++.

The problem though is that I don't know if I can start small with
doing my conversion of the engine to C++. I have at least a hundred
global variables I use all over the place. That said I could
probably clean up a lot of those by making them parameters in
subroutines. And maybe that's what I should start doing.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

Karl E. Peterson

9/14/2011 8:19:00 PM

Tony Toews formulated on Wednesday :
> On Wed, 14 Sep 2011 03:56:18 -0500, ralph <nt_consulting64@yahoo.net>
> wrote:
>
>>> 2) Convert the VB6 modules to C++. Preferably using a tool that will
>>> do most of the work. Preferably 95%+ but yeah, right.
>>>
>>> Huge PITA in doing the conversion of course. Bugs, etc, etc.
>>>
>>
>> Don't even go there and here is why in your own words ...
>>
>>> I've never worked with C++ The code in the modules is about 11K
>>> lines of code which includes the 2,600 lines of code in the API
>>> module.
>>>
>>
>> Conversion is a non-trival exercise even for those very familar with
>> both sides. Any 'automatic' tool would only leave you with 11k of
>> goobly-gook. You're better off to do it manually and learn as you go.
>> It will go faster than you think and your C++ skills will grow with
>> you. If the "GUI" is that simple then consider writing simple dialogs
>> in C++.
>
> The problem though is that I don't know if I can start small with
> doing my conversion of the engine to C++. I have at least a hundred
> global variables I use all over the place. That said I could
> probably clean up a lot of those by making them parameters in
> subroutines. And maybe that's what I should start doing.

Or use a single global object or structure. That helps me focus and
really justify any additions, or more easily find things that really
don't deserve that scope.

--
..NET: It's About Trust!
http://vfre...

Tony Toews

9/14/2011 8:43:00 PM

On Wed, 14 Sep 2011 13:18:49 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:

>> The problem though is that I don't know if I can start small with
>> doing my conversion of the engine to C++. I have at least a hundred
>> global variables I use all over the place. That said I could
>> probably clean up a lot of those by making them parameters in
>> subroutines. And maybe that's what I should start doing.
>
>Or use a single global object or structure. That helps me focus and
>really justify any additions, or more easily find things that really
>don't deserve that scope.

Thanks. I was thinking of that too a bit later.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

(Mike Mitchell)

9/15/2011 5:56:00 AM

On Wed, 14 Sep 2011 13:18:49 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:

>Tony Toews formulated on Wednesday :
>> On Wed, 14 Sep 2011 03:56:18 -0500, ralph <nt_consulting64@yahoo.net>
>> wrote:
>>
>>>> 2) Convert the VB6 modules to C++. Preferably using a tool that will
>>>> do most of the work. Preferably 95%+ but yeah, right.
>>>>
>>>> Huge PITA in doing the conversion of course. Bugs, etc, etc.
>>>>
>>>
>>> Don't even go there and here is why in your own words ...
>>>
>>>> I've never worked with C++ The code in the modules is about 11K
>>>> lines of code which includes the 2,600 lines of code in the API
>>>> module.
>>>>
>>>
>>> Conversion is a non-trival exercise even for those very familar with
>>> both sides. Any 'automatic' tool would only leave you with 11k of
>>> goobly-gook. You're better off to do it manually and learn as you go.
>>> It will go faster than you think and your C++ skills will grow with
>>> you. If the "GUI" is that simple then consider writing simple dialogs
>>> in C++.
>>
>> The problem though is that I don't know if I can start small with
>> doing my conversion of the engine to C++. I have at least a hundred
>> global variables I use all over the place. That said I could
>> probably clean up a lot of those by making them parameters in
>> subroutines. And maybe that's what I should start doing.
>
>Or use a single global object or structure. That helps me focus and
>really justify any additions, or more easily find things that really
>don't deserve that scope.

I've had my AppValues UDT for donkey's years. Works for me. E.g.

Private Type AppValuesType
Busy As Boolean
Cancel As Boolean
Paused As Boolean
hMixer As Long
INIfilepath As String
LogFolder As String
TEMPfilepath As String
CurrentVersion As String
Terminate As Boolean
ErrorNumber As Long
ErrorLine As Long
ErrorDescription As String
ErrorSource As String
LastDLLError As Long
SuppressPopupMessages As Boolean
Channel As Integer
Volume As Integer
KeyData(-7 To 7, 0 To 1) As String
MIDI_CmdDataLengths(0 To 7) As Integer
CurrentStatusBarMessage As String
KeyHighlight(0 To 1) As Long
MediaWriteProtected As Boolean
InitialTempo As Integer
GeneralTimerAction As Long
Scratchpad As New Collection
MidiInput As MidiInputType
End Type

Other apps simply take the core AppValues and modify them as
necessary.

MM

Tony Toews

9/15/2011 6:40:00 AM

On Tue, 13 Sep 2011 21:34:54 -0600, Tony Toews
<ttoews@telusplanet.net> wrote:

>2) Convert the VB6 modules to C++. Preferably using a tool that will
>do most of the work. Preferably 95%+ but yeah, right.

I just realized another benefit of putting the "engine" code in C++.
I should be able to easily port it to 64 bit if required for some
interesting stuff I have in mind to do in the distant future.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/ac...
Tony's Microsoft Access Blog - http://msmvps.com/blo...
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeup...

microsoft.public.vb.general.discussion

Your thoughts on converting parts of a VB6 app to C++

Tony Toews

ralph

Mayayana

(nobody)

GS

(nobody)

Tony Toews

Karl E. Peterson

Tony Toews

(Mike Mitchell)

Tony Toews

x Login to ForumsZone