Delphi - Form in DLL - Hints not showing

Question

I have a Delphi form inside a DLL (I know that this restricts the use of the DLL to Delphi but this is not a problem in this case).

The DLL exports a function ShowForm that looks roughly like this:

procedure ShowForm (App : TApplication);
begin
  OldApp := Application;
  try
    Application := App;
    MyForm := TMyForm.Create (nil);
    try
      MyForm.ShowModal;
    finally
      FreeAndNil (MyForm);
    end;
  finally
    Application := OldApp;
  end;
end;

Now on the form I use a TAdvOfficeHint (from the TMS component pack). Unfortunately the hints do not show up.

Am I missing something here? How can I make the form behave exactly as it would if I showed it from the main application?

Thanks!

You can keep it as dll, but at least compile your exe and dll with the runtime packages. You will run into more and more issues like this if you don't use runtime packages. Really... You already found others yourself: http://stackoverflow.com/questions/2250291/exceptions-and-dll-in-delphi — Lars Truijens, Feb 17 '10 at 18:01

Ondrej Kelle · Accepted Answer · 2010-02-17T13:03:29.947

5

I don't know TAdvOfficeHint but I guess it hooks Application.OnShowHint to set its own THintWindowClass, and even if both the main executable and the DLL are linking in the TMS unit, they each have their own copy of the class which is where things go wrong.

Assigning Application is not enough: there are other global variables, like Screen, Mouse, etc. Others are even hidden in the implementation so I'd say your chances to make the form behave exactly as from the main application are slim.

edited Feb 17 '10 at 13:03

answered Feb 17 '10 at 12:08

Ondrej Kelle

36,941
2
65
128

This seems correct: as a possible solution: is it possi ble to make the dll a package? This way you can be sure that you have only one Application and one Screen object in your address space. – Ritsaert Hornstra Feb 17 '10 at 12:21
1

Yes, that would help. If possible, either make your DLL a runtime package or at least compile both the DLL and the main application to use runtime packages. – Ondrej Kelle Feb 17 '10 at 12:25
Thanks and +1! Anything I can do without switching to packages? – jpfollenius Feb 17 '10 at 12:28
As they explained, no. Or you can stop using TAdvOfficeHint and come up with another hint solution. – Warren P Feb 17 '10 at 13:47

score 1 · Answer 2 · answered Feb 17 '10 at 12:42

1

Just found the reason why it does not work. As TOndrej states, TAdvOfficeHinthooks Application.OnShowHint and internally executes the following line of code:

FHintInfo.Assign (AHintInfo);

Assign internally uses a dynamic type check

if (Source is TAddvHintInfo) then ...

which fails due to the separate type registries of the DLL and the main application.

I have run into this problem a few times now and maybe I really have to switch to runtime packages to avoid all this stuff.

Anyway, if there's anything I can do to prevent this, please comment.

answered Feb 17 '10 at 12:42

jpfollenius

16,456
10
90
156

Perhaps you could try to rewrite it to check the class name instead and then hardcast: if Source.ClassNameIs('TAdvHintInfo') then with TAdvHintInfo(Source) do ... – Ondrej Kelle Feb 17 '10 at 13:06
I used this a couple of times before. I would prefer not to touch the sources. But this seems to be the only way, so thank you! – jpfollenius Feb 17 '10 at 13:12
1

That code is not guaranteed (the class name hack in the comment above) to run without crashing. – Warren P Feb 17 '10 at 13:48
Sorry. I thought it was obvious. :-) Yes, it's an ugly, dirty, dangerous hack. Don't do this at home. – Ondrej Kelle Feb 17 '10 at 14:03
3

More importantly, don't do this AT WORK. :-) – Warren P Feb 17 '10 at 14:58

score 1 · Answer 3 · edited Feb 17 '10 at 15:48

1

Wrong setting of Application.

Try this and see if it solves your problem:

procedure ShowForm (AppHandle : THandle);
begin
  OldAppHandle := Application.Handle;
  try
    Application.Handle := AppHandle;
    ........
  finally
    Application.Handle := OldAppHandle;
  end;
end;

edited Feb 17 '10 at 15:48

mghie

32,028
6
87
129

answered Feb 17 '10 at 15:40

APZ28

997
5
4

score 0 · Answer 4 · answered Feb 17 '10 at 14:24

0

I guess in Delphi 2006 and later versions you can call System.ShareMemoryManager method in the EXE code, so that its memory manager is shared with other modules loaded in the process memory space.

answered Feb 17 '10 at 14:24

vcldeveloper

7,399
2
33
39

I have included `SimpelShareMem` in both the application and the DLL. Shouldn't this have the same effect? And is the type registry problem related with the memory manager? – jpfollenius Feb 17 '10 at 14:27
3

Without runtime packages, you can share modules, but if the VCL classes are not in a shared package then mainexe::TObject will not be equal to mydll::TObject, until you enable runtime packages. Why are you so set against runtime packages? – Warren P Feb 17 '10 at 14:59
Well it seems Warren is right, I will delete this answer later. Sorry. – vcldeveloper Feb 17 '10 at 15:05
Because it would mean a lot of effort. – jpfollenius Feb 17 '10 at 15:28

Delphi - Form in DLL - Hints not showing

4 Answers4

Linked