tags:

views:

367

answers:

4

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!

+4  A: 

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.

TOndrej
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
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.
TOndrej
Thanks and +1! Anything I can do without switching to packages?
Smasher
As they explained, no. Or you can stop using TAdvOfficeHint and come up with another hint solution.
Warren P
A: 

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.

Smasher
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 ...
TOndrej
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!
Smasher
That code is not guaranteed (the class name hack in the comment above) to run without crashing.
Warren P
Sorry. I thought it was obvious. :-) Yes, it's an ugly, dirty, dangerous hack. Don't do this at home.
TOndrej
More importantly, don't do this AT WORK. :-)
Warren P
A: 

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.

vcldeveloper
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?
Smasher
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
Well it seems Warren is right, I will delete this answer later. Sorry.
vcldeveloper
Because it would mean a lot of effort.
Smasher
A: 

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;
APZ28