UniGUI Form in DLL Library

[InteriArt]

Hi.

 

Does anyone know a way to put unigui form in a DLL and call it from main application?

I managed to build sample with exe calling dll and kinda creating unigui form but it fires exception "invalid property path MonitoredKeys.Keys"

 

Thanks.

UniGUI_DLLTest.zip

[InteriArt]

Kinda found solution for this problem.

By enabling "Link with runtime packages" to both DLL and EXE projects, then recompiling - everything seems to work at least at this simple sample.

 

Would be nice to see working solution where "Link with runtime packages" is not required.

[merolarosa]

Hi,

I have the same problem error "invalid property path MonitoredKeys.Keys". I even tried it with enabling "Link with runtime packages" but still the problem exists.

here is my code its in C++ Builder:

 

Host App Header:

//---------------------------------------------------------------------------

#ifndef MainH
#define MainH
//---------------------------------------------------------------------------
#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include <uniGUIForm.hpp>
#include "Dlls.h"
#include "uniButton.hpp"
#include "uniGUIBaseClasses.hpp"
#include "uniGUIClasses.hpp"
#include "DllHostFormU.h"
//---------------------------------------------------------------------------
typedef void (*__declspec(dllimport) __stdcall TExecuteUniForm)(HWND CallingApp, TUniGUIApplication *Application);
//---------------------------------------------------------------------------
class TMainForm : public TUniForm
{
__published: // IDE-managed Components
TUniButton *UniButton1;
void __fastcall UniButton1Click(TObject *Sender);
private: // User declarations
TExecuteUniForm ExecuteUniForm;
public: // User declarations
__fastcall TMainForm(TComponent* Owner);
};
//---------------------------------------------------------------------------
TMainForm *MainForm(void);
//---------------------------------------------------------------------------
#endif

Host App cpp:

void __fastcall TMainForm::UniButton1Click(TObject *Sender)
{
 Uniguiapplication::TUniGUIApplication
if (ParamCount() > 0)
{
HINSTANCE Dll;
try
{
if (LoadDll(Dll, ParamStr(1)))
{
ExecuteUniForm = (TExecuteUniForm) GetDllFunc(Dll,"ExecuteUniForm");
ExecuteUniForm(Application->Handle, UniApplication);
}
}
__finally
{
// UnLoadDll(Dll);
}
}
}
//---------------------------------------------------------------------------

Dll code file:

#include <vcl.h>
#include <windows.h>
#include "uniGUIApplication.hpp"
#include "uniGUIForm.hpp"
#include "UniGuiDllFormU.h"
#include <UniGUIMainModule.hpp>
#include <uniGUIForm.hpp>
#include "UniGuiDllFormU.h"


#pragma hdrstop
#pragma argsused

#define DLLEXPORT __declspec(dllexport) __stdcall

//TApplication *ThisApp = NULL;

extern "C" {
//---------------------------------------------------------------------------
TUniForm* DLLEXPORT ExecuteUniForm(HWND CallingApp, TUniGUIApplication *Application)
{
//if (!ThisApp)
// {
// ThisApp = Application;
// Application->Handle = CallingApp;
// }

//I even tried this and it did not work
//((TUniDllForm*)Application->UniMainModule->GetFormInstance(__classid(TUniDllForm)))->ShowModal();

TUniDllForm *UniDllForm = new TUniDllForm(UniApp);

try
 {
 UniDllForm->Show();
 }
__finally
 {
 delete UniDllForm;
 }
}
//---------------------------------------------------------------------------
}
//---------------------------------------------------------------------------
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
//if (reason == DLL_PROCESS_DETACH)
// {
// if (ThisApp)
// Application = ThisApp;
//    }
//
return 1;
}
//---------------------------------------------------------------------------

Please, any help will be appreciated.

 

Regards

[mika]

I have this same problem.

 

This kind of functionality would be very useful for us. Most of our clients can use generic (One-Size-Fits-For-All-ish) version of our software but there are some clients who require very specific features that nobody else need. If we could build "Add-on modules" for these clients, it would solve many problems for us.

 

If feature like this is possible to implement, I'd love to see "UniGUI AddOn" or "UniGUI Library" as a new option UniGUI Project wizard. If, however, this is not possible, I would like to know at least some kind of "dirty" hack to accomplish functionality like this.

 

-- Mika

[Farshad Mohajeri]

I have this same problem.

 

This kind of functionality would be very useful for us. Most of our clients can use generic (One-Size-Fits-For-All-ish) version of our software but there are some clients who require very specific features that nobody else need. If we could build "Add-on modules" for these clients, it would solve many problems for us.

 

If feature like this is possible to implement, I'd love to see "UniGUI AddOn" or "UniGUI Library" as a new option UniGUI Project wizard. If, however, this is not possible, I would like to know at least some kind of "dirty" hack to accomplish functionality like this.

 

-- Mika

 

This issue is resolved.

[Farshad Mohajeri]

http://www.unigui.com/doc/online_help/index.html?using-runtime-packages.htm

[Farshad Mohajeri]

Kinda found solution for this problem.

By enabling "Link with runtime packages" to both DLL and EXE projects, then recompiling - everything seems to work at least at this simple sample.

 

Would be nice to see working solution where "Link with runtime packages" is not required.

 

Link with runtime packages" is needed. Otherwise,  DLL and EXE will use separate instances of uniCore library which will lead to confliction and error.

[mika]

Okay. Thank you. I  will test this in some point. It would be nice and in my opinion more easy and simple to achieve this without using runtime packages but it's good that implementing this functionality with runtime packages is at least an option

[Farshad Mohajeri]

Actually, you need to link with standard BPLs. Linking dynamically with  uniGUI runtime BPLs is enough.

[mika]

Thank you for clarification. I will try this and see if it's suitable for us.