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: Paul Clement on 4 Feb 2010 14:29 On Thu, 04 Feb 2010 10:35:28 -0800, Karl E. Peterson <karl(a)exmvps.org> wrote: � Paul Clement wrote: � > The bottom line is that your COM wrapper to the .NET component will have to � > be a 32-bit ActiveX EXE - you cannot run a 32-bit DLL in a 16-bit process � > space. � � Beat me to it. Your response appeared right as I hit Send on mine. � Scary, huh? <g> Great minds think alike. ;-) � > Or, the alternative is to upgrade your VB app to 32-bit as others have � > mentioned. � � The out of process approach is ugly, no doubt. Particularly if someone � decides to upgrade their system to x64. In that case, this band-aid � won't stop the hemorrhage. Yup, pretty much game over from a 16-bit standpoint. Of course if they're still running a 16-bit app it sort of begs the question which version of the OS they are using. Paul ~~~~ Microsoft MVP (Visual Basic)
From: Ralph on 4 Feb 2010 14:25 Paul Clement wrote: > 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)
From: Ralph on 4 Feb 2010 14:32 Paul Clement wrote: > > 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. > > I don't believe for a second you aren't sure what I was getting at. <g> However, who am I to argue with two such distinguished individuals. (Both of whom are in agreement for once! How scary is that?) Can't test it myself, but should be easy enough for the OP to do. -ralph
From: Karl E. Peterson on 4 Feb 2010 14:47 Paul Clement wrote: > � Beat me to it. Your response appeared right as I hit Send on mine. > � Scary, huh? <g> > > Great minds think alike. ;-) That was the scary part, yeah. <g> > � > Or, the alternative is to upgrade your VB app to 32-bit as others have > � > mentioned. > � > � The out of process approach is ugly, no doubt. Particularly if someone > � decides to upgrade their system to x64. In that case, this band-aid > � won't stop the hemorrhage. > > Yup, pretty much game over from a 16-bit standpoint. Of course if they're > still running a 16-bit app it sort of begs the question which version of the > OS they are using. He said XP, but you know those rascally users. Heck, even *I* moved to Win7x64. -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 4 Feb 2010 14:53
Ralph wrote: > Paul Clement wrote: >> >> 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. > > I don't believe for a second you aren't sure what I was getting at. <g> > > However, who am I to argue with two such distinguished individuals. (Both of > whom are in agreement for once! How scary is that?) You think *you're* scared??? <bg> > Can't test it myself, but should be easy enough for the OP to do. I just fired up a Win95 VM, and build a quick 32-bit ActiveX EXE using VB4/32. Then opened VB3, and had absolutely no problem connecting to it. (Once I remembered how to set the freakin' project properties! Man, it's amazing how primitive VB4 was. <g>) Thunks.CThunk (build with VB4/32): Option Explicit Private Declare Function GetSystemDirectory Lib "kernel32" Alias "GetSystemDirectoryA" (ByVal lpBuffer As String, ByVal nSize As Long) As Long Private Const MAX_PATH = 260 Public Property Get SysDir() As String Dim Buffer As String Dim nRet As Long ' Very low tech, but effective. Buffer = String$(MAX_PATH, 0) nRet = GetSystemDirectory(Buffer, Len(Buffer)) If nRet Then SysDir = Left$(Buffer, nRet) End Property Form1 (running in VB3 IDE): Sub Command1_Click () Dim obj As object Set obj = CreateObject("Thunks.CThunk") MsgBox obj.SysDir End Sub No problem. :-) -- ..NET: It's About Trust! http://vfred.mvps.org |