Lieven De Foor (b-inside) asked a question.
Hi,
Has anyone succeeded in using a .NET UserControl in classic ABL GUI?
There are supposed to be ways to create COM wrappers for .NET controls (https://docs.microsoft.com/en-us/dotnet/framework/interop/how-to-create-com-wrappers) and even Telerik has some documentation on it (https://docs.telerik.com/devtools/winforms/knowledge-base/wrapping-a-net-user-control-as-an-activex) but we haven't succeeded in getting this to work in classic ABL.
In particular, trying to add an OCX to the AppBuilder design canvas does not seem to show our newly registered COM wrapped control in the selection list. Manually browsing to the .tlb file and trying to open it returns an error.
Anyone with more succes?
Or are we trying something that is not technically possible?
Not a straight answer to your question. But what we usually do is to embed the ABL window in the GUI for .NET Window Container so that the ABL Window is in a .NET Form. And then we place .NET Controls in the same form (partially) overlapping the Window Container/ABL window.
Microsoft used to ship a tool called TstCon32 (ActiveX Control Test Container) with Visual Studio in which you can test your OCX's.
It is no longer supplied but I was able to build it using https://gitlab.com/dalevine/TstCon32
When running you can insert any registered OCX, using a UI that resembles the OCX selection UI from AppBuilder.
What's immediatelly apparent is that the list is a lot longer in this application, and I can choose my custom (or Teleriks example) control, and that seems to work fine as ActiveX from there!
So there must be some other rules that AppBuilder is applying to decide to show and/or be able to use a perfectly valid OCX...
No one from Progress development that can shed some light on this? Why is the MS tool showing more available OCXs than the AppBuilder dialog?
We get that list from what's in the registry under HKEY_CLASSES_ROOT\CLSID. All of the registered controls are there. If it's not there, it won't show up in the list. I can't find it now in this thread, but I thought you said that you could not register this wrappered control using regsvr32. If that is the case, that is the source of the problem. And I don't know why that would be.
Hi Laura, .NET controls wrapped as OCX are to be registered with regasm.exe instead of regsvr32.
But even when using the Browse button in the AppBuilder dialog to manually browse and open either the .dll or .tlb file, loading fails.
So what is the criterion in AppBuilder to be able to load an ocx when the MS tool (which is ancient as well) seems to have no issue loading this kind of ocx's...
OK. I have a theory. In the regsitry, under the specific classId key for each control, we look for a subkey labelled inProcServer32. Maybe for this there is something else instead or it is in a different section of the registry. Can you run regedit, and click on the HKEY_CLASSES_ROOT key in the tree. From there you can search for the name of your .dll. Do you find it? Can you tell me what the complete registry path is to that entry.
Hi Laura,
The test control is called ActiveXTestLibrary.UserControl and searching for the dll name I found the following in the registry:
Compared to a "classic" ocx (e.g. one made in VB6) this structure is quite different.
I found some not very usefull info regarding the above "mscoree.dll" here: https://stackoverflow.com/questions/2927970/regasm-writes-mscoree-dll-into-registry-key-inprocserver32
Below an example of an in-house built VB6 ocx that works fine in AppBuilder (i.e. shown in OCX "Choose Control" dialog in AppBuilder):
https://docs.microsoft.com/en-us/dotnet/framework/interop/registering-assemblies-with-com and https://flylib.com/books/en/2.53.1/com_interop_and_regasmexe.html might contain useful info as well...
Right - WOW6432Node... I couldn't remember the name of that, but that's what I was thinking. The control picker code does not look there since the code was written before that even existed! So are you sure that 2nd set is what you get for one that works? You may also have keys directly under HKEY_CLASSES_ROOT/CLSID, because I believe that is the only place we look. Maybe, it would be worth trying to add a registry entry yourself. You would create this key for your mipsimageview.ocx for example:
HKEY_CLASSES_ROOT\CLSID\{FA72E7AD-C6A6-11D4-B6FE-0050DA51D966}\InprocServer32
Under there you'd have 2 String values:
(Default) REG_SZ c:\\Workspace\\glimsdev117\\glims_dev_pro\\glims-bin\\ocx\\mipsimageview.ocx
ThreadingModel REG_SZ Apartment
Of course you need Admin rights. I can't seem to add anything in my registry even if I run with Admin privileges! Not like the old days!!! 😟
I could find another reference to the working classic mipsimageview.ocx in
[HKEY_CLASSES_ROOT\TypeLib\{FA72E7AB-C6A6-11D4-B6FE-0050DA51D966}\1.0\0\win32]
@="c:\\Workspace\\glimsdev117\\glims_dev_pro\\glims-bin\\ocx\\mipsimageview.ocx"
Would that be the place where AppBuilder looks?
According to the links I found above you should not directly add a reference to a .NET assembly you want to load as COM control, but instead need "mscoree.dll" as intermediate which is responsible for translating the COM calls to the managed .NET world...
Could you tell me a bit more about cntr.dll I found in my seach (see one of the logs below)?
I believe this one might contain the code to read the registry, register controls etc... and might be the dll that is currently not capable of working with .NET assemblies as COM?
The dll doesn't seem to be available on my machine, so I'm a bit confused it is referenced in ADE code...