Problems with ActiveX exe
Hello guys / girls,
I'm having some problems with using my ActiveX exe server in another project.
It was fine till few days ago.
Compatibility is set and I didn't have any messages that it was broken.
I created an ActiveX server exe and want to use it in my another project. I use it with early binding because I need the events.
Now when I try to use it it gives me the error 430 "class does not support automation or expected interface"
In the client app I have this reference:
Code:
Reference=*\G{BA0FBC84-7332-4E71-BDFB-DE88079C60A5}#1.1#0#VirtualForm2.exe#VirtualForm 2.0
and the .VBR file of the ActiveX exe contains this entries:
Code:
VB5SERVERINFO
VERSION=2.0.9
APPDESCRIPTION=VirtualForm 2.0
HKEY_CLASSES_ROOT\Typelib\{BA0FBC84-7332-4E71-BDFB-DE88079C60A5}\1.1 = VirtualForm 2.0
HKEY_CLASSES_ROOT\Typelib\{BA0FBC84-7332-4E71-BDFB-DE88079C60A5}\1.1\0\win32 = VirtualForm2.exe
HKEY_CLASSES_ROOT\Typelib\{BA0FBC84-7332-4E71-BDFB-DE88079C60A5}\1.1\FLAGS = 0
HKEY_CLASSES_ROOT\VirtualForm2.VFTextBox\CLSID = {2B0EC796-C16E-4EE6-9FAA-4F73E03B1993}
HKEY_CLASSES_ROOT\CLSID\{2B0EC796-C16E-4EE6-9FAA-4F73E03B1993}\ProgID = VirtualForm2.VFTextBox
HKEY_CLASSES_ROOT\CLSID\{2B0EC796-C16E-4EE6-9FAA-4F73E03B1993}\Version = 1.1
HKEY_CLASSES_ROOT\CLSID\{2B0EC796-C16E-4EE6-9FAA-4F73E03B1993}\Typelib = {BA0FBC84-7332-4E71-BDFB-DE88079C60A5}
HKEY_CLASSES_ROOT\CLSID\{2B0EC796-C16E-4EE6-9FAA-4F73E03B1993}\LocalServer32 = VirtualForm2.exe
HKEY_CLASSES_ROOT\INTERFACE\{93F6E4CC-D6AC-424F-9143-4C062512B303} = VFTextBox
HKEY_CLASSES_ROOT\INTERFACE\{93F6E4CC-D6AC-424F-9143-4C062512B303}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{93F6E4CC-D6AC-424F-9143-4C062512B303}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{93F6E4CC-D6AC-424F-9143-4C062512B303}\Typelib = {BA0FBC84-7332-4E71-BDFB-DE88079C60A5}
HKEY_CLASSES_ROOT\INTERFACE\{93F6E4CC-D6AC-424F-9143-4C062512B303}\Typelib\"version" = 1.1
HKEY_CLASSES_ROOT\VirtualForm2.VirtualForm\CLSID = {1D26E07F-8F30-437E-A37C-2E2CA9CBBA47}
HKEY_CLASSES_ROOT\CLSID\{1D26E07F-8F30-437E-A37C-2E2CA9CBBA47}\ProgID = VirtualForm2.VirtualForm
HKEY_CLASSES_ROOT\CLSID\{1D26E07F-8F30-437E-A37C-2E2CA9CBBA47}\Version = 1.1
HKEY_CLASSES_ROOT\CLSID\{1D26E07F-8F30-437E-A37C-2E2CA9CBBA47}\Typelib = {BA0FBC84-7332-4E71-BDFB-DE88079C60A5}
HKEY_CLASSES_ROOT\CLSID\{1D26E07F-8F30-437E-A37C-2E2CA9CBBA47}\LocalServer32 = VirtualForm2.exe
HKEY_CLASSES_ROOT\INTERFACE\{D5393612-8267-49BA-8CE2-789C6444F6D4} = VirtualForm
HKEY_CLASSES_ROOT\INTERFACE\{D5393612-8267-49BA-8CE2-789C6444F6D4}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{D5393612-8267-49BA-8CE2-789C6444F6D4}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{D5393612-8267-49BA-8CE2-789C6444F6D4}\Forward = {54175B73-8259-4D0E-9CE7-2CE4654BCF1C}
HKEY_CLASSES_ROOT\INTERFACE\{54175B73-8259-4D0E-9CE7-2CE4654BCF1C} = VirtualForm
HKEY_CLASSES_ROOT\INTERFACE\{54175B73-8259-4D0E-9CE7-2CE4654BCF1C}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{54175B73-8259-4D0E-9CE7-2CE4654BCF1C}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{54175B73-8259-4D0E-9CE7-2CE4654BCF1C}\Typelib = {BA0FBC84-7332-4E71-BDFB-DE88079C60A5}
HKEY_CLASSES_ROOT\INTERFACE\{54175B73-8259-4D0E-9CE7-2CE4654BCF1C}\Typelib\"version" = 1.1
HKEY_CLASSES_ROOT\INTERFACE\{10051DA6-3B03-4734-8D6D-3B0749290CE8} = VirtualForm
HKEY_CLASSES_ROOT\INTERFACE\{10051DA6-3B03-4734-8D6D-3B0749290CE8}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{10051DA6-3B03-4734-8D6D-3B0749290CE8}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{10051DA6-3B03-4734-8D6D-3B0749290CE8}\Forward = {BC89F75C-9C39-412E-9025-C73C97771047}
HKEY_CLASSES_ROOT\INTERFACE\{BC89F75C-9C39-412E-9025-C73C97771047} = VirtualForm
HKEY_CLASSES_ROOT\INTERFACE\{BC89F75C-9C39-412E-9025-C73C97771047}\ProxyStubClsid = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{BC89F75C-9C39-412E-9025-C73C97771047}\ProxyStubClsid32 = {00020420-0000-0000-C000-000000000046}
HKEY_CLASSES_ROOT\INTERFACE\{BC89F75C-9C39-412E-9025-C73C97771047}\Typelib = {BA0FBC84-7332-4E71-BDFB-DE88079C60A5}
HKEY_CLASSES_ROOT\INTERFACE\{BC89F75C-9C39-412E-9025-C73C97771047}\Typelib\"version" = 1.1
Re: Problems with ActiveX exe
Why did you not keep the ActiveX-Host as simple as suggested in the other thread?
(only having a single Constructor-Class with only two Methods)...
When you make it more complex as needed (Interface-wise, as well as Implementation-wise),
you will run into exactly the problems you now encounter.
And this won't happen, when your Ax-Exe does contain only a handful of CodeLines, which you will
never need to maintain (because they will not need to be "fixed" or "enhanced").
Here again, all the code which is ever needed in that Ax-Exe-Host (e.g. in a single public Class, named cConstructor):
Code:
Option Explicit 'for regfree instancing from 32bit-AX-Dlls, this exe needs DirectCOM.dll placed beside its own Binary
Private Declare Function GetInstanceEx Lib "DirectCOM" (spFName As Long, spClassName As Long, Optional ByVal UseAlteredSearchPath As Boolean = True) As Object
Public Function CreateInstance32(ByVal ProgID As String) As Object
Set CreateInstance32 = CreateObject(ProgID)
End Function
Public Function CreateInstance32RegFree(ByVal DllFileName As String, ByVal ClassName As String) As Object
Set CreateInstance32RegFree = GetInstanceEx(StrPtr(DllFileName), StrPtr(ClassName))
End Function
Your Main-Project should remain within a normal 32Bit AX-Dll (to be able to run it fast - without any marshalling - inside 32bit-Processes).
Olaf
Re: Problems with ActiveX exe
Hi Olaf
Thank you for responding. I've been trying to contact you in the last few weeks, but unsuccessful. Thank you for getting back.
The thing is that I need to expose the Ax-Exe to the users so that they can use it in 32-bit and in 64-bit version of Excel.
In scenario you are describing will I be able to also get the events with withevents in the Ax-Exe?
Re: Problems with ActiveX exe
I tried with with the code suggested:
Code:
Option Explicit 'for regfree instancing from 32bit-AX-Dlls, this exe needs DirectCOM.dll placed beside its own Binary
Private Declare Function GetInstanceEx Lib "DirectCOM" (spFName As Long, spClassName As Long, Optional ByVal UseAlteredSearchPath As Boolean = True) As Object
Public Function CreateInstance32(ByVal ProgID As String) As Object
Set CreateInstance32 = CreateObject(ProgID)
End Function
Public Function CreateInstance32RegFree(ByVal DllFileName As String, ByVal ClassName As String) As Object
Set CreateInstance32RegFree = GetInstanceEx(StrPtr(DllFileName), StrPtr(ClassName))
End Function
but can't get the events firing.
I'm still interested in the approach that Olaf suggested, to separate the Main-Project and to remain it within a normal 32Bit AX-Dll and to create a Ax-Exe-Host with one class but with the withevents and early binding. That will act like the mediator between the Client exe (that can be 32-bit or 64-bit) and the main 32Bit AX-Dll.
Will I gain on speed if I separete it in this 2 parts "32Bit AX-Dll" & "Ax-Exe-Host". Will the code execution in 32Bit AX-Dll be faster or will it be detained within the Ax-Exe-Host process that has called it?
Re: Problems with ActiveX exe
Quote:
Originally Posted by
Davor Geci
Will I gain on speed if I separete it in this 2 parts "32Bit AX-Dll" & "Ax-Exe-Host". Will the code execution in 32Bit AX-Dll be faster or will it be detained within the Ax-Exe-Host process that has called it?
You will gain speed (due to running a normal "Dll-based InProcess-Server"), when
(in case of a 32Bit Host-Process), you will instantiate your Dll directly (not over the AXexe-Host).
Quote:
Originally Posted by
Davor Geci
I tried with with the code suggested:
...but can't get the events firing.
As for the Events, unfortunately I don't have a VM set up currently, which does host
a 64Bit VBA-Environment ... but I think I've tested this a few years ago - and Events
should be marshalled from the AXExe-Host properly, when you declare the
Instance-Variable properly typed and WithEvents in VBA-64.
The only 64bit-testing I was able to do here now, was with the Windows-Scripting-Host -
and there the "32bit-Events from a 32bit-Dll-Class" were received within the 64bit-WSH...
The following Zip contains a VB6 (32bit) AXExe-Host - and two VBScripts, which make use of Forms
from a "normal VB6-compiled Dll" (vbRichClient5.dll) - so that should be quite similar to your scenario:
http://vbRichClient.com/Downloads/Ev...64BitHosts.zip
(needs a registered vbRichClient5 on your machine - and please compile the AXExe-Project first, before running the Scripts)
In case the above does work (showing a Form, which you can click, reporting the received Event in its Caption) -
the next test you could do (still with the vbRichClient5.dll as an example of a 32bit-InProcess-Server) -
would be within VBA-64.
In a VBA-Userform (something that remains alive for a while) - could you declare a WithEvents-Variable
(after putting a reference to vbRichClient5 into the Excel-64-Project) - something similar to the following
VB6-Code (which you could test in the VB6-IDE first, after you compiled the AXExe-Host from the above Zip):
VB6-IDE-code, which you would need to adapt to VBA64-Form-Code
Code:
Option Explicit
Private AXH32 As Object, WithEvents tmrTest As cTimer
Private Sub Form_Load()
Set AXH32 = CreateObject("AxHost32.cConstructor")
Set tmrTest = AXH32.CreateInstance32("vbRichClient5.cTimer")
tmrTest.Interval = 500
tmrTest.Enabled = True
End Sub
Private Sub tmrTest_Timer()
Debug.Print "Timer-Event, received at: " & Time
End Sub
Private Sub Form_Unload(Cancel As Integer)
Set tmrTest = Nothing 'cleanup the Timer-Proxy-Instance
Set AXH32 = Nothing 'cleanup the AXExe-Helper-Instance
End Sub
Just something to experiment with - please let me know what you find out...
Olaf
