How to call a VB6 ActiveX COM dll from VB3, both running on Win32?
in [Visual Basic]
|
Prev: Problem updating Service reference
Next: How to use the WebBrowser control to open an Office document
From: Ralph on 4 Feb 2010 13:37 CY wrote: > Like all said above, upgrade if you can... > > But it might be worth the trouble to do it in steps. (If you got VB4, > skip 5 I think and then go 6) My comm line (I dont think that existed > in VB3, but I got one) became a Picture Box and so on, think 3-->4 was > a big step. but that work seems a bit more productive than writing a > wrapper. > My first reaction was that would be a waste of time, BUT on further reflection - assuming the OP had or could obtain a full copy of VB4 - it did include a 'upgrade' tool to convert VB3 to VB4 - that would probably save some time. VB4 at least still recognized the older controls etc. Popping VB3 into VB6 would likely be a greater adventure, than working with VB4. Something else... I've forgot just when, but didn't one have to deliberately save VB 'source' files as text, otherwise VB saved its files in a binary format. I doubt those old pcode files would load into VB6 (????). -ralph
From: Ralph on 4 Feb 2010 13:51 Karl E. Peterson wrote: > Larsken wrote: >> So with my time running out I really hope that someone here on this >> forum has a good solution on (at first) how to call this VB6 COM dll >> or another similar GUI - less object from VB 3.0 ? > > The problem you're having is that you're trying to load a 32-bit > library into a 16-bit process. Cut out a few words in that last > sentence, to the *critical* part: "in-process". No can do. > > Create the 32-bit COM server as an ActiveX EXE, which will run > "out-of-process", and this approach should fly. (I hope I haven't > just ruined your "can't be done" excuse for rewriting the whole > project? <g>) > He would still SOL, so you haven't ruined a thing. Late or early binding, IUnknown or IDispatch (Automation), Standard DLL or ActiveX - 16-bit can't talk to 32-bit without a custom mediator, or indirectly through system services (Registry, files, etc). -ralph
From: Karl E. Peterson on 4 Feb 2010 14:15 Ralph wrote: > Karl E. Peterson wrote: >> Larsken wrote: >>> So with my time running out I really hope that someone here on this >>> forum has a good solution on (at first) how to call this VB6 COM dll >>> or another similar GUI - less object from VB 3.0 ? >> >> The problem you're having is that you're trying to load a 32-bit >> library into a 16-bit process. Cut out a few words in that last >> sentence, to the *critical* part: "in-process". No can do. >> >> Create the 32-bit COM server as an ActiveX EXE, which will run >> "out-of-process", and this approach should fly. (I hope I haven't >> just ruined your "can't be done" excuse for rewriting the whole >> project? <g>) > > He would still SOL, so you haven't ruined a thing. > > Late or early binding, IUnknown or IDispatch (Automation), Standard DLL or > ActiveX - 16-bit can't talk to 32-bit without a custom mediator, or > indirectly through system services (Registry, files, etc). I've had no problem talking to a 16-bit ActiveX EXE from a 32-bit app. Why would it be more difficult to go the other way? Isn't COM the mediator? -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 4 Feb 2010 14:17 Ralph wrote: > My first reaction was that would be a waste of time, BUT on further > reflection - assuming the OP had or could obtain a full copy of VB4 - it did > include a 'upgrade' tool to convert VB3 to VB4 - that would probably save > some time. VB4 at least still recognized the older controls etc. Popping VB3 > into VB6 would likely be a greater adventure, than working with VB4. I actually found a shrinkwrapped copy of VB4EE the other day, in a closet, and was wondering if it might still have any value. > Something else... I've forgot just when, but didn't one have to deliberately > save VB 'source' files as text, otherwise VB saved its files in a binary > format. I doubt those old pcode files would load into VB6 (????). Yeah, I fired up VB3 the other day, and saw that the options still used binary by default. So it definitely had to be toggled to text there. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Paul Clement on 4 Feb 2010 14:18
On Thu, 4 Feb 2010 12:51:49 -0600, "Ralph" <nt_consulting64(a)yahoo.com> wrote: � Karl E. Peterson wrote: � > Larsken wrote: � >> So with my time running out I really hope that someone here on this � >> forum has a good solution on (at first) how to call this VB6 COM dll � >> or another similar GUI - less object from VB 3.0 ? � > � > The problem you're having is that you're trying to load a 32-bit � > library into a 16-bit process. Cut out a few words in that last � > sentence, to the *critical* part: "in-process". No can do. � > � > Create the 32-bit COM server as an ActiveX EXE, which will run � > "out-of-process", and this approach should fly. (I hope I haven't � > just ruined your "can't be done" excuse for rewriting the whole � > project? <g>) � > � � He would still SOL, so you haven't ruined a thing. � � Late or early binding, IUnknown or IDispatch (Automation), Standard DLL or � ActiveX - 16-bit can't talk to 32-bit without a custom mediator, or � indirectly through system services (Registry, files, etc). � � -ralph � Not really sure what you're getting at. I used to use this COM out of process thunking mechanism all the time back in the days of 16 and 32-bit VB 4.0, especially when I needed to use a 16-bit DLL library. As a matter of fact I distinctly remember automating 32-bit Office apps from 16-bit VB. Paul ~~~~ Microsoft MVP (Visual Basic) |