application.exename

[derseitzer]

Hallo Leute,

ich wollte gerade eigentlich wie gewohnt meinen Speicherort finden und dort den 'picture' Ordner per Programm finden, allerdings funktioniert folgender Befehl nicht mehr:
dir:= ExtractFilePath(application.Exename); //undeklarierter bezeichner 'Exename'

Er funktioniert wahrscheinlich nicht mehr, da ich ein Firemonkey Projekt erstellt habe, das auf Android laufen soll. Deshalb habe ich "Vcl.Forms" nicht unter "uses" stehen..
Gibt es einen komplementären Befehl für FMX oder sollte ich nur etwas unter uses hinzufügen?:/

Vielen dank im voraus!

[Uwe Raabe]

Um plattformunabhängig zu sein, solltest du besser die in System.IOUtils bereitgestellten Pfade verwenden (

Delphi-Quellcode:

TPath.GetHomePath

,

Delphi-Quellcode:

TPath.GetDocumentsPath

usw.). Da du in den meisten Fällen eh nicht in den Pfad schreiben darfst, in dem deine Anwendung liegt, bist du mit diesen Wrappern eigentlich besser bedient.

[derseitzer]

klappt super ich danke dir:)

[Fritzew]

Zitat:

bist du mit diesen Wrappern eigentlich besser bedient.

Gebe ich Dir recht, aber ein Wrapper für

Delphi-Quellcode:

ExtractFilePath(ParamStr(0))

würde auch nicht schaden.....

[Glados]

Zitat:

Um plattformunabhängig zu sein, solltest du besser die in System.IOUtils bereitgestellten Pfade verwenden (TPath.GetHomePath , TPath.GetDocumentsPath usw.). Da du in den meisten Fällen eh nicht in den Pfad schreiben darfst, in dem deine Anwendung liegt, bist du mit diesen Wrappern eigentlich besser bedient.

Gibt es in TPath auch eine Funktion die das Verzeichnis der eigenen Exe zurückgibt?

[Uwe Raabe]

Zitat:

Zitat von Fritzew (Beitrag 1377475)

Gebe ich Dir recht, aber ein Wrapper für

Delphi-Quellcode:

ExtractFilePath(ParamStr(0))

würde auch nicht schaden.....

Zitat:

Zitat von Glados (Beitrag 1377476)

Gibt es in TPath auch eine Funktion die das Verzeichnis der eigenen Exe zurückgibt?

Unter Windows ist das

Delphi-Quellcode:

TPath.GetLibraryPath

.

Eine Übersicht der Bedeutungen für die verschiedenen Plattformen gibt es hier: Standard-RTL-Pfadfunktionen für alle unterstützten Zielplattformen

[Fritzew]

Aah Danke, ist mir entgangen. Bei GetLibraryPath habe ich an sowas wie wie System32 und co gedacht. Man sollte mehr lesen und weniger denken. :shock:

[Glados]

Ich wollte eigentlich meine alte Funktion welche ShGetSpecialFolderLocation aufruft rausschmeißen und durch die TPath-Varianten ersetzen.
Aber CSIDL_DESKTOPDIRECTORY und CSIDL_STARTMENU scheint es wohl nicht zu geben.

[jaenicke]

Zitat:

Zitat von Glados (Beitrag 1377482)

Aber CSIDL_DESKTOPDIRECTORY und CSIDL_STARTMENU scheint es wohl nicht zu geben.

Die sind ja auch Windows-spezifisch und somit gibt es keine Notwendigkeit für einen plattformunabhängigen Wrapper via TPath.

[Glados]

Schön wäre es dennoch und kürzeren Code hätte man dann auch.

[Uwe Raabe]

Zitat:

Zitat von Glados (Beitrag 1377503)

Schön wäre es dennoch und kürzeren Code hätte man dann auch.

Bitteschön:

Delphi-Quellcode:

interface

uses
  System.IOUtils;

type
  TPathHelper = record helper for TPath
  private
  public
    function GetDesktopFolder: string;
    function GetStartMenuFolder: string;
  end;

implementation

uses
  Winapi.SHFolder, Winapi.ShlObj;

function TPathHelper.GetDesktopFolder: string;
var
  LStr: array[0 .. MAX_PATH] of Char;
begin
  SetLastError(ERROR_SUCCESS);

  if SHGetFolderPath(0, CSIDL_DESKTOPDIRECTORY, 0, 0, @LStr) = S_OK then
    Result := LStr;
end;

function TPathHelper.GetStartMenuFolder: string;
var
  LStr: array[0 .. MAX_PATH] of Char;
begin
  SetLastError(ERROR_SUCCESS);

  if SHGetFolderPath(0, CSIDL_STARTMENU, 0, 0, @LStr) = S_OK then
    Result := LStr;
end;

[Glados]

Ok an Class-Helper habe ich ehrlich gesagt nicht gedacht, da ich öfter mal Schlechtes darüber gelesen habe.
:thumb:

[Fritzew]

Klasse!
Nur eine Kleinigkeit , Result sollte initialisiert werden.......

Zitat:

Zitat von Uwe Raabe (Beitrag 1377505)

Bitteschön:

Delphi-Quellcode:

interface

uses
  System.IOUtils;

type
  TPathHelper = record helper for TPath
  private
  public
    function GetDesktopFolder: string;
    function GetStartMenuFolder: string;
  end;

implementation

uses
  Winapi.SHFolder, Winapi.ShlObj;

function TPathHelper.GetDesktopFolder: string;
var
  LStr: array[0 .. MAX_PATH] of Char;
begin
  SetLastError(ERROR_SUCCESS);
  Result := ''; // Wenn schon denn Schon 
  if SHGetFolderPath(0, CSIDL_DESKTOPDIRECTORY, 0, 0, @LStr) = S_OK then
    Result := LStr;
end;

function TPathHelper.GetStartMenuFolder: string;
var
  LStr: array[0 .. MAX_PATH] of Char;
begin
  SetLastError(ERROR_SUCCESS);
 Result := ''; // Wenn schon denn Schon 
  if SHGetFolderPath(0, CSIDL_STARTMENU, 0, 0, @LStr) = S_OK then
    Result := LStr;
end;

Zitat:

Zitat von Glados (Beitrag 1377503)

Ok jetzt weiß ich warum die Dinger verpöhnt sind - zumindest ich weiß nicht einmal wie man das benutzt.

Den Helper in eine Unit, diese einbinden wo die Funktionen daraus gebraucht werden und fertig.

[Glados]

Ich habs jetzt so gemacht

Delphi-Quellcode:

var
 PathHelper: TPath;

[Fritzew]

Zitat:

Zitat von Glados (Beitrag 1377511)

Ich habs jetzt so gemacht

Delphi-Quellcode:

var
 PathHelper: TPath;

Das brauchst Du nicht.
Einfach die Unit einbinden und dann zb :

Delphi-Quellcode:

 myDektop := Tpath.GetDesktopFolder;

Der ClassHelper erweitert Tpath um die funktionen

[Luckie]

Ich hätte die Methoden allerdings GetWinDesktopFolder und GetWinStartMenuFolder genannt. Wenn dann noch welche für MacOS oder Linux dazu kommen, kann man sie auch entsprechend benennen und kommt nicht durcheinander.

[Fritzew]

Zitat:

Zitat von Luckie (Beitrag 1377516)

Ich hätte die Methoden allerdings GetWinDesktopFolder und GetWinStartMenuFolder genannt. Wenn dann noch welche für MacOS oder Linux dazu kommen, kann man sie auch entsprechend benennen und kommt nicht durcheinander.

Wieso? Das ist doch der Zweck der CrossPlattform Routinen?
Wenn ich den Desktop will ist es doch egal ob ich aktuell unter Win oder OSX bin.
Ist doch z.B bei TPath.GetDownloadsPath genau so oder?

[Luckie]

Äh. Ja. War ein Denkfehler von mir. :roll: