分享
 
 
 

Creating Forms that are stored in DLLs

王朝delphi·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

There are lots of resources and solutions out there on the internet that are specific to this problem, however, in using the BusinessSkinForm components, that are tightly integrated with the VCL and messaging, I came across a few problems with the standard approaches.

The final solution came with the assistance of Steve Woods (aka Reconics).

The main problem with storing Forms in dlls and being able to create instances of them from within a host exe is that when Delphi compiles up a dll, it has its own TApplication and TScreen instances (as well as other info as to be discovered).

This means that the DLL and the EXE message loops are different, the RTTI information is different, and causes lots of problems like the well know "cannot assign a TFont to a TFont" message.

So how do we Coax the form in the DLL to think it is part of the EXE, we replace the Application and Screen Object in the DLL with the reference to the EXE's Application and Screen.

This is a standard approach that you will find on the net. However there is one additional element that needs to be passed from EXE to DLL and this is the tricky one.

From Steve Woods -

“The problem is caused by the ControlAtom local variable in the Controls.pas units. When the controls unit initializes it creates a global atom based on the string 'ControlOfs' + the HInstance and thread ID of the application and stores the atom in the ControlAtom local variable.

All well and good. Then when new wincontrols are added to the application a pointer to the control is stored under the window handle using the SetProp API function. This allows Delphi

to get the TWinControl of a Handle.

The CM_MouseEnter etc. events are generated from the TApplication.DoMouseIdle method. In order to get the current wincontrol under the mouse, and thus pass the required messages, its searches for a property with a Atom equal to the local ControlAtom variable stored in the Controls units.

This all works fine for standalone apps but when you start putting forms in DLL's the following happens:

The controls unit is initialized again for the DLL. This creates a new global atom and stores it in the Controls unit local variable, so you now have TWO control global atoms, one for the main app and one for the DLL.

And thus, when the Application.DoMouseIdle method tries to find a property stored with the same name (atom) as the application on a DLL form, it fails. To solve this I had to hack the controls.pas units a little. I added a routine : Function GetControlAtom : Pointer that returns @ControlAtom from the controls units.

Then in your DLL's you initialize by passing the ControlAtom from the application Controls units and set this value in the Controls unit of the DLL:

eg

Library ADLL;

Uses

...

forms,

Controls, //Add this here so it initializes unit before we try and change GetControlAtom;

...

procedure CreateForm(App : TApplication;Scr : TScreen;RealControlAtom :

Integer);

Var

P : ^Word;

Begin

If (OldApp = Nil) Then

Begin

OldApp := Application;

OldScr := Screen;

P := GetControlAtom;

OldAtom := P^;

Application := App;

Screen := Scr;

P^ := RealControlAtom;

end;

TForm1.Create(Application.MainForm);

end;

and make sure you clean-up before you unload the dll."

Stage 1) The ControlAtom variable is private to the controls.pas unit so we need to change Controls.pas for the EXE and DLL projects

Take a copy of controls.pas from the delphisourcevcl directory and save it into a directory that the EXE project and DLL project can access.

In the Interface Section add the function declaration for the function that will return the address of the current ControlAtom variable.

function GetControlAtom : pointer;

In the implementation section add the GetControlAtom function.

function GetControlAtom : pointer; begin result := @ControlAtom; end;

We now have an exposed function that will return the address of the Control Atom Variable.

Stage 2) Setting up the DLL exported functions

Add the modified Controls.pas to the project so it appears in the Project manager. Delphi

will then use this source in preference to the standard controls.dcu.

We now need to provide a DLLInitialization procedure and a DLLFinalization Procedure. The DLLInitialization must be called before trying to use any forms from the DLL, usually this is

called just after loading the dll into memory. The DLLFinalization procedure should be called before the DLL is unloaded from memory.

Below is an example of the code needed to be exposed in the DLL. Notice the dll exports 3 functions/procedures DLLInitiailize, DLLFinalize and GetInstance

GetInstance is the call that actually returns an instance of a the dlls Form.

library plugin;

uses

ShareMem,

SysUtils,

Classes,

Windows,

Forms,

Controls in 'Controls.pas',

pluginform in 'pluginform.pas' {MyPlugin};

{$R *.res}

var

OldApp : TApplication;

OldScreen : TScreen;

OldControlAtom : TAtom;

procedure DLLInitialize(App : TApplication; Scr : TScreen; RealControlAtom :Integer);

var

x : pointer;

p : ^Word;

begin

If (OldApp = Nil) Then

Begin

// store away the current application, screen and control atom

OldApp := Application;

OldScreen := Screen;

p := GetControlAtom;

OldControlAtom := p^;

// Assign the EXE's application, screen and control atom

Application := App;

Screen := Scr;

p^ := RealControlAtom;

end;

ASkin := Skin;

end;

function GetInstance(AOwner : TComponent) : TForm;

begin

// create an instance of the form

result := TMyPlugin.create(Application.MainForm);

end;

procedure DLLFinalize;

var

p : ^Word;

begin

// restore the DLL's application, screen and control atom

p := GetControlAtom;

p^ := OldControlAtom;

Screen := OldScreen;

Application := OldApp;

end;

exports

GetInstance, DLLInitialize, DLLFinalize;

begin

OldApp := nil;

OldScreen := nil;

OldControlAtom := 0;

end.

Stage 3) Setting up the EXE.

Add the modified Controls.pas to the project so it appears in the Project manager. Delphi

will then use this source in preference to the standard controls.dcu.

Declare some procedure / function types to be used to reference the exported procs in the dll.

type

TDLLInitialize = procedure (App : TApplication; Scr : TScreen; RealControlAtom : Integer);

TDLLFinalize = procedure;

TGetInstance = function (AOwner : TComponent) : TForm;

Add a variable to store the DLL HInstance in

var

FInst : HINST;

Add a procedure to Load the DLL and initialize it

procedure LoadDLL

var

AInit : TMyInitialize;

p : ^WORD;

begin

// get the address of the Exe's control atom

p := GetControlAtom;

FInst := LoadLibrary('plugin.dll');

AInit := GetProcAddress(FInst,'DLLInitialize');

if assigned(AInit) then

begin

// pass the TApplication, TScreen and value of the Control Atom

AInit(Application,Screen,p^, bsCompressedStoredSkin1);

end;

end;

Add a procedure to Finalize the DLL and Unload it

procedure UnloadDLL

var

AProc : TMyFinalize;

begin

// unload the dll after asking the dll to restore it's original application, screen and ControlAtom

AProc := GetProcAddress(FInst,'DLLFinalize');

if assigned(AProc) then

begin

AProc;

end;

if FInst <> 0 then FreeLibrary(FInst);

end;

Add a procedure to create an instance procedure CreateAForm;

var

AProc : TGetInstance;

AForm : TMyPlugin;

begin

// get an instance of the form in the dll - not that the dll creates it... not the exe.

AProc := GetProcAddress(FInst,'GetInstance');

if assigned(APRoc) then

begin

AForm := TMyPlugin(AProc(self));

AForm.Name := 'Form' + Formatdatetime('hhnnss',now); // give it a unique name

end;

end;

So you now have an EXE and DLL that both use the modified controls.pas, that correctly passes the EXE's application object, screen object and ControlAtom to the DLL to trick the DLL into thinking it is part of the EXE application.

Procedure CreateForm(App : TApplication;Scr : TScreen;RealControlAtom : Integer);

Var

P : ^Word;

Begin

If (OldApp = Nil) Then

Begin

OldApp := Application;

OldScr := Screen;

P := GetControlAtom;

OldAtom := P^;

Application := App;

Screen := Scr;

P^ := RealControlAtom;

end;

end;

So you now have an EXE and DLL that both use the modified controls.pas, that correctly passes the EXE's application object, screen object and ControlAtom to the DLL to trick the DLL into thinking it is part of the EXE application.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有