Gegenstück zum delphi TApplication
-
- Beiträge: 369
- Registriert: Do 8. Jun 2017, 18:21
- OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
- CPU-Target: 64Bit
- Wohnort: Wien
Gegenstück zum delphi TApplication
Bei Delphi gibt es die Klasse TAppication mit einem globalen Singleton Application, dort lassen sich so Dinge wie das Handle der Anwendung, der Name des EXE-Files und vieles andere abfragen. In Lazarus/Free Pascal habe ich nichts gefunden, was dem entsprechen würde.
Jetzt würde ich gerade gerne den Dateinamen des Exe-Files abfragen, finde ihn aber nicht. Aber auch andere Properties der Application-Instanz brauche ich gelegentlich. Wo findet man diese Dinge in Free Pascal?
Jetzt würde ich gerade gerne den Dateinamen des Exe-Files abfragen, finde ihn aber nicht. Aber auch andere Properties der Application-Instanz brauche ich gelegentlich. Wo findet man diese Dinge in Free Pascal?
-
- Beiträge: 1910
- Registriert: Di 23. Sep 2014, 17:46
- OS, Lazarus, FPC: Win10 | Linux
- CPU-Target: x86_64
Re: Gegenstück zum delphi TApplication
Die TApplication Klasse mit der Globalen Variable Application (also kein richtiger Singelton) gibt es in der Unit Forms.
Sie enthält aber viele Sachen nicht die es in Delphi gibt, die einfach nicht Cross Plattform verfügbar sind. Das Handle einer Application z.B. exsistiert in der Form gar nicht in *nix. Genauso mit dem namen der Executable. In Windows ist das einfach da der erste Param (ParamStr(0)) immer den Vollen Pfad zur Executable gibt. Unter *nix ist das der Pfad mit dem die Exec gestartet wurde (z.b. nur der exec name wenn es im Suchpfad liegt, oder der Absolute oder relative pfad, je nachdem was exec übergeben wurde). Unter Linux kann man den Vollständigen pfad auslesen indem man den Symlink /proc/self/exec auflöst, das geht aber wiederum nicht unter Mac OS (auch ein POSIX system). Nach dem POSIX standard muss es nichtmal eine möglichkeit geben die echte Exec abzufragen, daher ist es nicht in der LCL
Sie enthält aber viele Sachen nicht die es in Delphi gibt, die einfach nicht Cross Plattform verfügbar sind. Das Handle einer Application z.B. exsistiert in der Form gar nicht in *nix. Genauso mit dem namen der Executable. In Windows ist das einfach da der erste Param (ParamStr(0)) immer den Vollen Pfad zur Executable gibt. Unter *nix ist das der Pfad mit dem die Exec gestartet wurde (z.b. nur der exec name wenn es im Suchpfad liegt, oder der Absolute oder relative pfad, je nachdem was exec übergeben wurde). Unter Linux kann man den Vollständigen pfad auslesen indem man den Symlink /proc/self/exec auflöst, das geht aber wiederum nicht unter Mac OS (auch ein POSIX system). Nach dem POSIX standard muss es nichtmal eine möglichkeit geben die echte Exec abzufragen, daher ist es nicht in der LCL
-
- Beiträge: 369
- Registriert: Do 8. Jun 2017, 18:21
- OS, Lazarus, FPC: Windows 10 64bit, Lazarus 2.0.10, FPC 3.2.0
- CPU-Target: 64Bit
- Wohnort: Wien
Re: Gegenstück zum delphi TApplication
Ok, danke. An paramstr(0) habe ich gar nicht mehr gedacht, das ist natürlich unter Windows die Lösung.
Das ist dann wohl das mühsame an einer Cross-Platform-Entwicklungsumgebung, dass sie alle Mängel von allen in Frage kommenden Zielplattformen kombiniert.
Das ist dann wohl das mühsame an einer Cross-Platform-Entwicklungsumgebung, dass sie alle Mängel von allen in Frage kommenden Zielplattformen kombiniert.
Re: Gegenstück zum delphi TApplication
Warf hat geschrieben:Die TApplication Klasse mit der Globalen Variable Application (also kein richtiger Singelton) gibt es in der Unit Forms.
Sie enthält aber viele Sachen nicht die es in Delphi gibt, die einfach nicht Cross Plattform verfügbar sind. Das Handle einer Application z.B. exsistiert in der Form gar nicht in *nix. Genauso mit dem namen der Executable. In Windows ist das einfach da der erste Param (ParamStr(0)) immer den Vollen Pfad zur Executable gibt. Unter *nix ist das der Pfad mit dem die Exec gestartet wurde (z.b. nur der exec name wenn es im Suchpfad liegt, oder der Absolute oder relative pfad, je nachdem was exec übergeben wurde). Unter Linux kann man den Vollständigen pfad auslesen indem man den Symlink /proc/self/exec auflöst, das geht aber wiederum nicht unter Mac OS (auch ein POSIX system). Nach dem POSIX standard muss es nichtmal eine möglichkeit geben die echte Exec abzufragen, daher ist es nicht in der LCL
Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.
Re: Gegenstück zum delphi TApplication
wp_xyz hat geschrieben:Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.
Auch mit einem Aufruf via Symlink getestet?
-
- Beiträge: 1910
- Registriert: Di 23. Sep 2014, 17:46
- OS, Lazarus, FPC: Win10 | Linux
- CPU-Target: x86_64
Re: Gegenstück zum delphi TApplication
wp_xyz hat geschrieben:Soll das heißen, dass Application.ExeName und ParamStr(0) unter Linux nicht funktionieren? Das deckt sich nicht mit den Ergebnissen des Tests, den ich eben gemacht habe.
Gibt es Application.ExeName unter Linux? Ich hab gestern kurz in die TApplication Definition in der Forms Unit angeschaut und da kein ExeName gefunden (hab aber nur kurz überflogen).
Paramstr(0) muss nicht den namen der Exec enthalten. z.B.:
Code: Alles auswählen
$ testapp arg1
paramstr> testapp arg1
$ ../testapp arg1
paramstr> ../testapp arg1
$ symlinkauftestapp arg1
paramstr> symlinkauftestapp arg1
$ /home/user/testapp arg1
paramstr> /home/user/testapp arg1
Ganz dumm gesagt, es ist immer das erste argument was man als erstes in die Kommandozeile eintippt, da das an execve übergeben wird. Unter Windows ist es immer der absolute Pfad zur Exe. Wie gesagt nach dem POSIX standard müssen die Betriebsysteme keine Möglichkeit bereitstellen die Orginal Exe zu finden. Linux und Mac OS erlauben es trozdem, es kann aber gut sein das es unter BSD z.B. nicht möglich wäre (ich kenn BSD nicht, weiß nur das es sich an den POSIX standard hält).
Richtig verrückt wirds wenn man einfach mal den starndard bricht und execve nicht den dateinamen übergibt:
Code: Alles auswählen
execl("/path/to/app", "irgendeinkomplettanderername", NULL)
Dann ist paramstr(0) von app einfach irgendeinkomplettanderername. Auch wenn das offiziell nicht definiert ist schluckt das sowohl Linux als auch Mac OS
Re: Gegenstück zum delphi TApplication
theo hat geschrieben:wp_xyz hat geschrieben:Auch mit einem Aufruf via Symlink getestet?
Ja, funktioniert auch. Nur bei einem Hard-Link kommt das Pfad zum Hardlink, aber das hätte ich auch genauso erwartet, und das gilt auch für Hardlinks unter Windows.
Re: Gegenstück zum delphi TApplication
Warf hat geschrieben:Gibt es Application.ExeName unter Linux?
Ja, steht allerdings beim Vorfahren TCustomApplication - krux der Vererbung... Und wenn man weiterschaut, ruft der Getter der Eigenschaft ExeName, GetExeName, nichts anderes als ParamStr(0) auf!
Das ist alles etwas seltsam:
TCustomApplication.GetExeName --> ParamStr(0) (wenn nicht "Darwin" definiert ist)
TApplication.GetExeName --> ParamStrUTF8(0) (klar, wegen UTF8-Unterstützung der LCL), aber GetExeName ist nicht virtuell
-
- Beiträge: 1910
- Registriert: Di 23. Sep 2014, 17:46
- OS, Lazarus, FPC: Win10 | Linux
- CPU-Target: x86_64
Re: Gegenstück zum delphi TApplication
wp_xyz hat geschrieben:Ja, funktioniert auch. Nur bei einem Hard-Link kommt das Pfad zum Hardlink, aber das hätte ich auch genauso erwartet, und das gilt auch für Hardlinks unter Windows.
Äußerst interresant, das ist eine eigenheit vom FPC.
C:
Code: Alles auswählen
#include <stdio.h>
int main(const int argc, const char** argv) {
for (int i=0; i<argc; printf("%s\n", argv[i++]);
return 0;
}
Pascal:
Code: Alles auswählen
Program Test;
{$Mode ObjFPC}{$H+}
var i: Integer;
begin
for i:=0 to ParamCount do WriteLn(ParamStr(0));
end.
Ergebnis:
Code: Alles auswählen
$ ./printArgsC
./printArgsC
$ ./printArgsPas
/home/user/printArgsPas