Robert wrote:
But nowadays, my customers want me to supply a 64-bit ActiveX as
well, since M$ Visual Studio requires a 64-bit ActiveX if they want to
compile their code for 64-bits.
Only if the ActiveX control is an in-process server (loaded into the calling
process). 64bit code can use a 32bit out-of-process server (running in its
own process).
If your ActiveX control is 32bit in-process, and you are having trouble updating
it to 64bit, you could always just keep it as 32bit and then register a 32bit
DLL Surrogate to host it as an out-process server.
DLL Surrogates
https://msdn.microsoft.com/en-us/library/windows/desktop/ms695225.aspx
Windows even provides a default DllSurrogate for this propose. Or you can
write your own custom surrogate.
64bit code can then talk to the 32bit surrogate, which will delegate to your
32bit control.
For example, even the simpler 32-bit control imports OK, and it shows
up in the list of registered ActiveX controls in the Import ActiveX
wizard, but when I try to place the imported wrapper component onto a
Delphi form, I get an error message "Class not registered" -- even
after I register it again!
HOW are you registering it? ActiveX registration is sensitive to many factors
- user account, 32bit/64bit, which in turn is senstive to Registry virtualization,
etc.
--
Remy Lebeau (TeamB)
First of all, Remy, I hope that somebody out there is paying you about a million bucks a year for the help you continue to provide to everyone. I have always gotten great help from reading your replies to me or anyone else. Thanks, for all you do!
My ActiveX was originally created by the ActiveX Wizard of the legacy compilers like Delphi 7. So it has been my understanding, from explanations in Eric Harmon's book Delphi Com Programming, that this was an in-process com server.
I will certainly study your link about DLL Surrogates. However, Embarcadero claims that RAD Studio 10 Seattle Pro is capable of producing 64-bit ActiveX controls, Since all of my code generators are set up to use those, I would prefer not to have to rewrite a dozen code generators at this time. I would greatly prefer to produce a 64-bit in-process ActiveX that can work with my existing generated code.
By the way -- I still have the Delphi source code that was originally generated by the legacy compiler. Several years ago, I found that compiling this for Win32 in Delphi XE2 produced a working Win32 ActiveX. Is it possible that compiling that legacy code for Win64 could produce a working 64-bit ActiveX?
HOW are you registering it? ActiveX registration is sensitive to many factors
- user account, 32bit/64bit, which in turn is senstive to Registry virtualization,
etc.
What I tried to do was to copy the 64-bit OCX (that Delphi compiled) to C:\Windows\System32, which I believe uses Microsoft's 64-bit regsvr32.exe to do the registration. I believe this is supposed to registers the ActiveX for all users. Here is the error message I get from Microsoft regsvr32.exe:
"The module 'HAX_1_4_10S.ocx' failed to load.
Make sure the binary is stored at the specific path or
debug it to check for problems with the binary or
dependent .DLL files.
Invalid access to memory location."
(The Microsoft error message is not very informative. WHAT memory location has the invalid access?)
I have not tried to use RAD Studio's TRegSvr.exe to register the 64-bit ActiveX. I should do that, in hopes that it might produce some more useful information than Microsoft did.
Please note that I have even tried to get RAD Studio 10 Seattle to make a new 32-bit version of my ActiveX from my working VCL control that I had installed into 10 Seattle. I used the menu item to register the new Win32 ActiveX, and then after I closed that project, I used menu item Component | Import to import the 32-bit ActiveX and make a wrapper control.
The next time I started RS 10 Seattle, I saw the wrapper control on the Component Palette. However, when I tried to USE that wrapper control by placing it on the main form of a little test program, the IDE gave me an error message "Class not registered."
This is one of those ambiguous error messages that drives me crazy. WHICH class is not registered? Not registered with WHAT? Is the ActiveX not registered with Windows? Or is it the wrapper class that is not registered with Delphi?
Re-registering the ActiveX did not change this, so it would seem that it is the class of the wrapper control itself that is (somehow) not registered with Delphi.
By the way, I then ran Microsoft's AxImp.exe to import this 32-bit ActiveX into Microsoft land, and used Visual Studio 2013 to verify that the 32 bit ActiveX works -- which also shows that it was in fact registered.
So I am blocked in 2 ways.
1) The 64-bit ActiveX fails to register with Windows, for reasons unknown. If it cannot register with Windows, I cannot even test it.
2) The 32-bit ActiveX seems to register with Windows, but it fails to register with Delphi.
By the way, lest anyone think that I am a Delphi hater, I most definitely love Delphi, and I have found it to be the most productive programming platform on the planet.
For a client, I have even tried to port this control to C#, so they could compile their apps for "any platform" in Visual Studio. But in trying to port this, I have run into dozens of concrete ways that Delphi makes things much easier for you than .NET. Generally, I find that when I run into some problem that I don't know how to handle, Delphi already has a 1-line solution, but Microsoft makes you write 20 lines or more, AFTER it takes up a lot of your time just trying to find out HOW to write that 20-line solution at all. Embarcadero's claim that "RAD Studio speeds development by up to 5X" is true, and probably an understatement.
If I ever get this thing working, I will post what I did here, so others can help. It looks to me as if ActiveX is kind of a dusty corner that most people don't come to anymore, and the Delphi documentation is kind of sketchy in spots.
Thanks again for your help. Any further suggestions would be most appreciated!
