Abfrage ob gerade für Delphi-Package kompiliert wird

[Bernhard Geyer]

Zitat von Neutral General:

Zitat von BerndS:

Funktioniert das wirklich ?

Zitat:

Und es ist problemlos möglich eine EXE auch als DLL in einer anderen EXE zu nutzen.

Ich habe das mal mit einer EXE unter XE7 getestet, aber durch die unterschiedliche Initialisierung eine EXE und DLL funktionierte das nicht. Gibt es da einen Trick?

Gruß Bernd

Was wolltest du denn genau machen?
Das reine Exportieren von Funktionen sollte ohne Probleme funktionieren.
Du hast halt bei einer Exe kein DllMain (zumindest hast du keinen Einfluss drauf), aber sonst ist eine DLL nur eine EXE mit nem gesetzten "DLL-Flag" im PE-Header

Wir überlagern die Delphi PNG-Klasse mit einer erweiterten PNG-Klasse welche auch weitere Methoden/Properties hat.
in der Anwendung wird die Delphi-PNG-Klasse mit TPicture.UnRegisterGraphicClass(TPNGImage) deregistriert sowie ein überlagern mittels TPNGObject = TUnserSuperPngObject gemacht.
Bei der Compilierung der Packages wirkt das aber nicht so das die Methoden welche auf Features der erweiterten PNG-Klasse zugreifen krachen.

[jbg]

Man kann zur Laufzeit unterscheiden zumindest zwischen DLL und EXE unterscheiden: IsLibrary.

Man könnte aber auch über FindHInstance/FindClassHInstance mit der eigenen HInstance Variable vergleichen, um herauszufinden, ob die PNG-Klasse in der selben DLL/EXE liegt.

[Uwe Raabe]

Zitat von jbg:

Man kann zur Laufzeit unterscheiden zumindest zwischen DLL und EXE unterscheiden: IsLibrary.

Na ja, man kann auch direkt abfragen, ob es ein Package ist: ModuleIsPackage

[jbg]

Zitat von Uwe Raabe:

ModuleIsPackage

Ich hatte, bevor ich geantwortet habe, noch nach "IsPackage" gesucht, da ich sowas im Kopf hatte (Einheitliche Benennung war noch nie "Delphi"'s Stärke)

[himitsu]

In ModuleIsPackage steckt aber auch IsPackage drin.

'nen intelligenter Filter der Codevervollständigung war auch noch nie deren Stärke.

[Uwe Raabe]

Zitat von jbg:

Ich hatte, bevor ich geantwortet habe, noch nach "IsPackage" gesucht, da ich sowas im Kopf hatte (Einheitliche Benennung war noch nie "Delphi"'s Stärke)

Aber man ist auf dem besten Weg:

Delphi-Quellcode:

var
  ModuleIsLib: Boolean;         { True if this module is a dll (a library or a package) }
  ModuleIsPackage: Boolean;     { True if this module is a package }
  ModuleIsCpp: Boolean;         { True if this module is compiled using C++ Builder }

[himitsu]

Ähhhhhhh, wozu ModuleIsCpp?
Wenn ich 'nen Code in C++ schreibe, dann ist das True und wenn ich den in Pascal/Delphi schreibe dann False?

Aber wenn ich in C++ schreibe, dann weiß ich das doch auch so?

[edit] Ich glaub es ist spät.
Beim CppBuilder kann man doch Delphi-Code einbinden, oder Delphi-Units oder irgendwie sowas.

Warum eigentlich nicht andersrum?
(OK, abgesehn von .OBJ)

[BerndS]

@Neutral General

Ich habe hier ein einfaches Projekt um das zu testen.

Delphi-Quellcode:

program ExeAsDLL;

uses
  WinApi.Windows,
  Vcl.Forms,
  Unit1 in 'Unit1.pas' {Form1};

{$R *.res}
procedure ShowDocument; stdcall;
begin
  WinApi.Windows.MessageBox(0, 'ShowDocument', 'ExeAsDLL', MB_ICONINFORMATION or MB_OK);
end;

exports ShowDocument;

begin
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TForm1, Form1);
  Application.Run;
end.

Der Test erfolgt mit:
rundll32 ExeAsDLL.exe ShowDocument
Unter Windows 7 kommt die bekannte Meldung Programm funktioniert nicht mehr unter W10 wird nichts angezeigt.
Gruß Bernd

[4dk2]

Zitat von jbg:

Delphi-Quellcode:

var
  ModuleIsLib: Boolean;         { True if this module is a dll (a library or a package) }
  ModuleIsPackage: Boolean;     { True if this module is a package }
  ModuleIsCpp: Boolean;         { True if this module is compiled using C++ Builder }

DANKE

Genau das habe ich für eine BPL gesucht, um ein Design-PKG zu vermeiden