[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Using vb6 with Office X64bits

avi

5/17/2012 11:01:00 PM

Hello,

I've a VB6 DLL called from a macro in an Excel add-in, which works
fine under Office X32b

In Office X64bits, I get an error "Activex component can't create
object" and it looks that it is quite impossible to call directly a
32bits dll from Office X64Bits

As a turnaround, I call the dll from a small VB6 exe and call the exe
from the macro. It works fine so far...

Is the turnaround correct and reliable?

Thanks
Avi
10 Answers

Karl E. Peterson

5/17/2012 11:15:00 PM

0

After serious thinking avi wrote :
> Hello,
>
> I've a VB6 DLL called from a macro in an Excel add-in, which works
> fine under Office X32b
>
> In Office X64bits, I get an error "Activex component can't create
> object" and it looks that it is quite impossible to call directly a
> 32bits dll from Office X64Bits
>
> As a turnaround, I call the dll from a small VB6 exe and call the exe
> from the macro. It works fine so far...
>
> Is the turnaround correct and reliable?

That might be as good as it gets. One thing I've wanted to try, but
haven't found time to mess with yet, would be using an out-of-process
ActiveX server, rather than an in-process one. In theory, that ought
to work, and would probably be far more robust than using your own
middleman EXE.

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


Schmidt

5/18/2012 12:05:00 AM

0

Am 18.05.2012 01:14, schrieb Karl E. Peterson:
> One thing I've wanted to try, but haven't found time to mess
> with yet, would be using an out-of-process ActiveX server,
> rather than an in-process one. In theory, that ought to
> work, and would probably be far more robust than using
> your own middleman EXE.

From my experience this *does* work reliably - though
somewhat slower, due to the marshaling-overhead -
and at the cost of registering an (albeit small)
additional ActiveX-Exe in the usual way for such Binaries.

So, such an ActiveX-Exe-Wrapper needs only to define
a single Public-Class, which then acts as an
*instantiation*-helper for the wrapped (32Bit) COM-Dlls.

For example there are some (Excel-)Users of my
SQLite-Wrapper-Classes, which are implemented in
a VB6-compiled 32Bit COM-Dll.

And what worked for them in XL-64 was a simple
ActiveX-Exe-based Instantiation-Class, which was
just handing out an internally (in the AX-Exe)
instantiated cConnection-Class:

'in the AX-Exe Public Class
Public Function GetConnection() as cConnection
Set GetConnection = New cConnection
End Function

The above was all there was to do, since cRecordset
and cCommand-Instances are able to be "derived"
from the already wrapped cConnection-Instance.

e.g. within XL-(64Bit-)VBA then:

Dim Cnn As cConnection
'use the CreateObject-Call against the AX-Exes PublicClass
Set Cnn = CreateObject("AXExeProj.PublicClass").GetConnection

'At this point Cnn holds a 64Bit-*Proxy*-Instance within
'the XL-64Bit Process, which got its Interface-Infos from
'the referenced 32Bit-Dll-Typelib without problems
'
'The real 32Bit-Cnn-Instance runs within the AX-Exe - and
'calls between the 64Bit-Cnn-Proxy and the 32Bit-Cnn-Instance
'are apparently marshaled without any hickups, even when
'one of the participants of this OutOfProcess-mechanism
'differs with regards to the "BitCount".

Cnn.OpenDB DBFileName 'this call is 64Bit-to-32Bit-marshaled already

Dim Rs As cRecordset
Set Rs = Cnn.OpenRecordset("Select Something From SomeTable")
'and the above Rs-retrieving-call works too, because the
'returned Rs-Instance was derived from the already marshaled
'Cnn - and therefore the real Rs-Instance runs within the
'ActiveX-Exe too - on the side of the XL-64Bit-VBA-environment
'there's (once again) only a 64Bit "Rs-Proxy-Object" at work...


Olaf

unknown

5/18/2012 3:47:00 AM

0

"avi" <aviben@bezeqint.net.il> wrote in message
news:eba12d89-fe85-4bf4-8c87-7f0f1521c169@dg7g2000vbb.googlegroups.com...
> Hello,
>
> I've a VB6 DLL called from a macro in an Excel add-in, which works
> fine under Office X32b
>
> In Office X64bits, I get an error "Activex component can't create
> object" and it looks that it is quite impossible to call directly a
> 32bits dll from Office X64Bits
>
> As a turnaround, I call the dll from a small VB6 exe and call the exe
> from the macro. It works fine so far...
>
> Is the turnaround correct and reliable?

COM supports creating objects in a surrogate process(Typically DLLHOST.EXE),
so you can talk to your AxDLL made with VB6 from 64-Bit VBA. You need to do
3 things to make this happen:

1 - Call CoCreateInstance() while specifying the flag CLSCTX_LOCAL_SERVER by
itself without specifying any of the other flags. The article below 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

How To Control Server Location in a Visual Basic Client
http://support.microsoft.com...

2 - Update the Declare statement to use "PtrSafe" keyword. See "Application
Programming Interface Compatibility" below:

Compatibility Between the 32-bit and 64-bit Versions of Office 2010
http://msdn.microsoft.com/en-us/library/ee6...

3 - Add DllSurrogate entry in the registry for your COM component, and set
it to empty string:

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

I am not sure if I missed anything else.


Ralph

5/18/2012 4:16:00 AM

0

On Thu, 17 May 2012 16:14:56 -0700, Karl E. Peterson <karl@exmvps.org>
wrote:


>
>That might be as good as it gets. One thing I've wanted to try, but
>haven't found time to mess with yet, would be using an out-of-process
>ActiveX server, rather than an in-process one. In theory, that ought
>to work, and would probably be far more robust than using your own
>middleman EXE.

Yea Gads!

What are you guys suggesting? Don't you'all know COM is dead?

-ralph
<g>

GS

5/18/2012 4:53:00 PM

0

Olaf,
This is an interesting approach! As you know I do a lot of Excel-based
apps (VB6/VBA) and so I've been trying to determine how to handle my
DLLs which contain the code for my Excel menus. The x64 Excel VBA
project places calls to an in-process DLL (now running reg-free thanks
to you) that uses CallByName to execute menu choices. The menus pass
the proc name via their 'Tag' property, and params via their
'Parameter' property. (The latter may be a delimited string but this is
no problem because the called proc expects this)

I'm already aware of using conditional declares and such things as
'PtrSafe', but I really would like a pure VB6 x32 'solution' so I don't
need to maintain multiple versions of my DLLs. Is what you're
suggesting here how I might implement my existing x86 projects to work
with x64Excel?

--
Garry

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


GS

5/18/2012 4:56:00 PM

0

Typo...

> Olaf,
> This is an interesting approach! As you know I do a lot of Excel-based apps
> (VB6/VBA) and so I've been trying to determine how to handle my DLLs which
> contain the code for my Excel menus.

The *x86* Excel VBA project places calls to an in-process DLL (now
running reg-free thanks to you) that uses CallByName to execute menu
choices.

> The menus pass the proc name via their
> 'Tag' property, and params via their 'Parameter' property. (The latter may be
> a delimited string but this is no problem because the called proc expects
> this)
>
> I'm already aware of using conditional declares and such things as 'PtrSafe',
> but I really would like a pure VB6 x32 'solution' so I don't need to maintain
> multiple versions of my DLLs. Is what you're suggesting here how I might
> implement my existing x86 projects to work with x64Excel?

--
Garry

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


Schmidt

5/21/2012 10:47:00 AM

0

Am 18.05.2012 18:55, schrieb GS:
> Typo...
>
>> Olaf,
>> This is an interesting approach! As you know I do a lot of Excel-based
>> apps (VB6/VBA) and so I've been trying to determine how to handle my
>> DLLs which contain the code for my Excel menus.
>
> The *x86* Excel VBA project places calls to an in-process DLL (now
> running reg-free thanks to you) that uses CallByName to execute menu
> choices.
>
>> The menus pass the proc name via their 'Tag' property, and params via
>> their 'Parameter' property. (The latter may be a delimited string but
>> this is no problem because the called proc expects this)
>>
>> I'm already aware of using conditional declares and such things as
>> 'PtrSafe', but I really would like a pure VB6 x32 'solution' so I
>> don't need to maintain multiple versions of my DLLs. Is what you're
>> suggesting here how I might implement my existing x86 projects to work
>> with x64Excel?
>

As posted, there's no real need, to "reimplement"
your 32Bit Dll Classes - you will only need to
"route" their instantiation through an ActiveX-Exe.

So instead of:

Set oMyClass = New cMyClass

you will need (in VBA64):

Set oMyClass = CreateObject("ActiveXExe.cInstRedirect").GetMyClass

The above line will then instantiate the appropriate
Proxy-Object within VBA64 (when in the GetMyClass-Function
of the cInstRdirect-Class of the AX-Exe, an internal
32Bit-Instance of cMyClass is created).

The DllSurrogate-based technique as outlined by Farnsworth
should work nearly similar - in both cases there is an
external (32Bit)Hosting-Process established, which serves
as an OutOfProcess-COM-Server then (communication over
marshaled COM-Calls, which are able to "bridge" the
64Bit COM-World (VBA64) to the 32Bit-(VB6)-COM-Dlls).

In bot cases you will need registry-entries though -
in case of the ActiveX-Exe you can establish the
needed entries with a commandline- (or shell-) call
(probably in Admin-Mode):
MyAXServer.exe /regserver

Not sure about the (over-all) efforts with the DllSurrogate-approach -
maybe these can be set "by hand" and a registry-helper-class
(or module) also directly from VBA.


Olaf

GS

5/21/2012 5:42:00 PM

0

Thanks, Olaf. I appreciate your attention to detail. It will certainly
be a learning exercise since I have no experience working with an
ActiveX.exe in VB6/VBA. The approach sounds interesting enough, though,
to invest time/effort. You make it seem so simple<g>...

--
Garry

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


Karl E. Peterson

5/21/2012 7:41:00 PM

0

Schmidt presented the following explanation :
> Am 18.05.2012 01:14, schrieb Karl E. Peterson:
>> One thing I've wanted to try, but haven't found time to mess
>> with yet, would be using an out-of-process ActiveX server,
>> rather than an in-process one. In theory, that ought to
>> work, and would probably be far more robust than using
>> your own middleman EXE.
>
> From my experience this *does* work reliably - though
> somewhat slower, due to the marshaling-overhead -
> and at the cost of registering an (albeit small)
> additional ActiveX-Exe in the usual way for such Binaries.

That's good to hear. I figured it ought to, and really need to play
with that someday. Heh, I guess, just as soon as folks actually start
using the 64-bit apps. Thanks!

> So, such an ActiveX-Exe-Wrapper needs only to define
> a single Public-Class, which then acts as an
> *instantiation*-helper for the wrapped (32Bit) COM-Dlls.

Slick!

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


Karl E. Peterson

5/21/2012 7:43:00 PM

0

ralph pretended :
> On Thu, 17 May 2012 16:14:56 -0700, Karl E. Peterson <karl@exmvps.org>
> wrote:
>
>
>>
>> That might be as good as it gets. One thing I've wanted to try, but
>> haven't found time to mess with yet, would be using an out-of-process
>> ActiveX server, rather than an in-process one. In theory, that ought
>> to work, and would probably be far more robust than using your own
>> middleman EXE.
>
> Yea Gads!
>
> What are you guys suggesting? Don't you'all know COM is dead?
>
> -ralph
> <g>

Mark Twain may have said it best... <bg>

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