Using Your Own .NET Designer Objects in Unmanaged Code – Designer Object Bridge

Many things can often be implemented significantly easier and faster in managed code than in unmanaged code, such as with Delphi or C++. Sometimes, there already exist ready-made .NET modules which contain the desired requirements and which need to be used in your own unmanaged application. But the question then is: How can a .NET module be made accessible to an unmanaged system?

In order to create this bridge between unmanaged and managed code, additional work is often necessary. Some form of communication layer is necessary which acts as an intermediary between the different “worlds”, or at least creates a connection. It is precisely for such cases that we have created such a bridge in List & Label 23: the “Designer Object Bridge”. With it, your own Designer objects which are implemented in .NET can not only be used in the .NET world, but also in your own unmanaged world, such as C++ or Delphi. Because the base code of List & Label was written in C++, this bridge is based on C++/CLI. With this bridge, it is now extremely easy and convenient to implement your own List & Label Designer objects in .NET and use them within your own applications and/or register them with List & Label. In order to demonstrate this requirement, two examples are provided which will be described in greater detail below.

Deutsche Post AG’s Internet Stamps
Starting with List & Label 22, it has been possible to use the Deutsche Post’s internet stamps (“Internetmarke”) — see also the blogpost on the Internetmarke. However, so far only managed (.NET) applications were able to use the Deutsche Post’s internet stamps with the List & Label .NET assembly combit.ListLabel[>=22].Internetmarke. However, with the Designer Object Bridge now available, internet stamps can also be used in your own unmanaged applications starting with List & Label 23.

TX Text Control
The use of formatted text via RTF is a common requirement for List & Label, and this can be realized out of the box with the installed RTF control from Microsoft. However, there are different versions of this RTF control for each version of the operating system, and the behavior of the control versions often also differs. Furthermore, the options are often also limited, in particular when dealing with tables. To this end, we have also recommended the TX Text Control as a better alternative in the past — see the KB article KBAE001309. Here too, the limitation that only .NET applications could benefit from the RTF rendering of the TX Text Control also applied. Now, the Designer Object Bridge can also be used in such cases to make the .NET TX Text Control accessible to a C++ or Delphi application in List & Label.

Designer Object Bridge
For details of how the implementation of such a Designer object in .NET can be realized such that the Designer Object Bridge is able to use it, please consult the updated programming example for the TX Text Control. But which steps are necessary in order to use your own .NET Designer object with the Designer Object Bridge?

1. The function ::LlSetOptionString() must be expanded for the option LL_OPTIONSTR_LLXPATHLIST(12) with the entry for the module of the Designer Object Bridge “combit.ListLabel.DesignerObjectBridge_x86.dll” or “combit.ListLabel.DesignerObjectBridge_x64.dll” – depending on the bitness of the List & Label used):

...
::LlSetOptionString(hJob, LL_OPTIONSTR_LLXPATHLIST, _T("combit.ListLabel.DesignerObjectBridge_x86.dll"));
...

Now the C++/CLI bridge will be loaded in List & Label. In order to now inform the Designer Object Bridge which .NET modules are to be loaded/utilized, a configuration file will need to be created.

2. The configuration file (“combit.ListLabel.DesignerObjectBridge_x86.dll.config” or “combit.ListLabel.DesignerObjectBridge_x64.dll.config” – depending on the bitness of the Designer Object Bridge used) must be located in the same folder as the Designer Object Bridge itself and have the following structure:

<configuration>
<assemblyPaths>
<path value="<ToDo: path to the managed .NET assembly>" />
<path value="<ToDo: path to another managed .NET assembly>" />
...
</assemblyPaths>
</configuration>

Example for using the provided internet stamp as a Designer object:

<configuration>
<assemblyPaths>
<path value=".combit.ListLabel23.Internetmarke.dll" />
</assemblyPaths>
</configuration>

3. If the Designer object needs to receive any options or parameters, they can be set using the function ::LlXSetParameter(). On the .NET implementation side, these options then need to be accepted in the overridden method OnSetOptionString() of the Designer object. Details on this can be obtained from the new programming example for the TX Text Control.

Example for the internet stamp:

...
::LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_OBJECT, _T("InternetmarkeObject"), _T("Internetmarke.PartnerId"), _T("<ToDo: Partner-ID>"));
::LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_OBJECT, _T("InternetmarkeObject"), _T("Internetmarke.KeyPhase"), _T("<ToDo: Key-Phase>"));
::LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_OBJECT, _T("InternetmarkeObject"), _T("Internetmarke.SignatureKey"), _T("<ToDo: Signature-Key"));
::LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_OBJECT, _T("InternetmarkeObject"), _T("Internetmarke.EulaText"), _T("<ToDo: optional EULA-Text"));
...

Example for TX Text Control:

...
::LlXSetParameter(hJob, LL_LLX_EXTENSIONTYPE_OBJECT, _T("TXTextObjectName"), _T("TxTextControl.RecalcTableLayout"), _T("0"));
...

Conclusion
With the new tool “Designer Object Bridge”, it is now extremely easy to implement any of your own Designer objects in .NET, which can then be used in the corresponding unmanaged application

Related Posts

Leave a Comment