After having successfully resolved by Visual Plugin display issue, I now have a design question regarding whether what I am trying to do is possible and supported.
I have two non-visual plugin libraries with a number of business logic implementations. Both need to access a shared data access library which needs to be initialized from Delphi with parameters. I now added a Visual Plugin library to the mix.
I would like to centralize the access from Delphi behind a “Gateway.dll” that provides me access to the business logic implementations, the visual plugins and a single database initialization point.
For the non-visual libraries this is working fine. The Gateway DLL returns instances of the non-visual libraries and I have access to all the business logic implementations.
The problem is with the visual plugin library. When loaded independently by the ModuleManager, the CreateVisualPlugin method finds the plugin in the library and displays it fine in Delphi.
When trying to access is through the instance returned by the Gateway DLL, the method can’t find the plugin. I tried various ways of specifying the path to the plugin to no avail.
Any thoughts? Is there a way to interrogate the Module Manager for information on accessing the visual library?
Below is an abbreviated code implementation of the Gateway DLL
namespace Finser.RegEGateway
{
[Plugin, NonVisualPlugin]
public partial class TPlgRegEGateway : NonVisualPlugin, IPlgRegEGateway
{
private IPlgRegELib fPlgRegELib;
private IPlgRegEUILib fPlgRegEUILib;
public bool SetConnectionParam(string aIniFile)
public bool ConnectBankDB(string aBankDbPath, string aBankDbName)
public IPlgRegELib PlgRegELib
{
get
{
if (fPlgRegELib == null)
fPlgRegELib = new TPlgRegELib();
return fPlgRegELib;
}
}
public IPlgRegEUILib PlgRegEUILib
{
get
{
if (fPlgRegEUILib == null)
fPlgRegEUILib = new TPlgRegEUILib();
return fPlgRegEUILib;
}
}
At first glance this should work, however it seems that something is wrong in the details.
Visual Plugin is defined correctly for sure, as it can be created via CreateVisualPlugin.
You can also attach Visual Studio as debugger tot the host app (be cure to uncheck Just My Code in debugger options) and then to try to access the Visual Plugin in the failing way. This will show what exactly fails on the .NET side (ie is it a not found reference, some initialization issue or something else)
Could you create a testcase where this issue reproduces? Just create a copy of your plugin dll, remove all business logic (replace method bodies with NotImplementedException) and UI elements from it and create a very simple host app that would reproduce the issue (one button that loads the plugin via CreateVisualPlugin and it works and other one where access to the plugin fails)
Thanks for the quick reply and sorry for the unclear description of the error. I am on the receiving end of that all the time myself so I should know better.
The CreateVisualPlugin method throws the err_UnknownPluginName exception regardless of how I specifiy the namespace path to the plugin.
I attached three projects for the components of the issue. What led me down this path is that when I obtain an instance of the RegEGateway NonVisualPlugin, the property RegELib (which is commented out right now) provides me access to all the business logic objects defined as custom interfaces.
I did not have to load RegELib.DLL or create a NonVisual instance of it. This is were my confusion comes in when dealing with the Visual plugin and how to access the Visual Plugins defined in RegEUILib.
Obviously, that worked and I might just finally understand the concepts I have to implement. Thanks for your help.
P.S.
Is there a way to manually integrate Hydra 4 into VS 2019. I realize the birth dates of these products don’t match, but if there is a procedure I could use to manually integrate the three components into the toolbox, it would help a lot.
Full integration is not possible. Visual Studio integration packages from Hydra 4 cannot be loaded into VS 2019.
Still partial integration is possible.
Install Hydra 4 on a host with supported VS version
Copy the c:\Program Files (x86)\RemObjects Software\ folder contents
On the VS 2019 host put these assemblies into some folder (f.e. c:\Hydra4 ):
RemObjects.Everwood.Live.dll
RemObjects.Hydra.Designtime.dll
RemObjects.Hydra.dll
RemObjects.Hydra.Host.dll
RemObjects.Hydra.WPF.dll
You have to reference RemObjects.Everwood.Live.dll and RemObjects.Hydra.Designtime.dll assemblies in your Hydra projects to let the .NET license compiler do its work. However these two
assemblies are used only at build time and should not be distributed with the application.
To add Hydra components to the WinForms toolbox please do the following:
Create a new Windows Forms project
Open main form designer
Right-click Toolbox and select Choose Items
In the dialog appeared (its initialization can take up to several minutes) press Browse and select assemblies stored in c:\Hydra4. Select RemObjects.Hydra.dll and RemObjects.Hydra.Host.dll.
Press Enter and HostPanel and ModuleManager components will appear in the Toolbox
Before using these components in a new project you’ll need to first add references to the Hydra assemblies to the project. Otherwise WinForms designer might fail.
