4. [wxWidgets] GetAppPath

[wxWidgets] GetAppPath

  • K

    Hallo,

    ausnahmsweise kein Problem im eigentlichen Sinne, eher im Gegenteil. Ich hab folgendes im wxWidgets Buch gelesen (wer keine Lust hat es durchzulesen: es geht um Schwierigkeit, den AppPath zu finden):

    wxBook schrieb:

    Finding the Application Path
    A common request from wxWidgets developers is a function to find the path of
    the currently executing application to enable the application to load data that
    is in the same directory. There is no such function in wxWidgets, partly because
    it’s difficult to achieve this reliably on all platforms, and partly to encourage
    the installation of data into standard locations (particularly on Linux).
    However, it can be convenient to put all the application’s files in the same
    folder, so in examples/chap20/findapppath, you can find code for a function
    wxFindAppPath:

    // Find the absolute path the application has been run from.
wxString wxFindAppPath(const wxString& argv0, const wxString& cwd,
const wxString& appVariableName = wxEmptyString,
const wxString& appName = wxEmptyString);

    argv0 is the value of wxApp::argv[0], which on some platforms gives the full
    pathname for the application.
    cwd is the current working directory (obtained with wxGetCwd), which is a
    hint that can be used on some platforms.
    appVariableName is the name of an environment variable, such as
    MYAPPDIR, that may have been set externally to indicate the application's location.
    appName is the prefix used in a bundle to allow the function to check the
    bundle contents for application location. For example, in the case of
    DialogBlocks, the argument is DialogBlocks, and on Mac OS X, the function
    will try to return <currentdir>/DialogBlocks.app/Content/MacOS for the executable
    location.
    Here’s an example of using wxFindAppPath:

    bool MyApp::OnInit()
{
wxString currentDir = wxGetCwd();
m_appDir = wxFindAppPath(argv[0], currentDir, wxT(“MYAPPDIR”),
wxT(“MyApp”));
...
return true;
}

    On Windows and Mac OS X, this reliably locates the executable path. On
    Unix, it works only if you run the application with the current directory set to
    the application directory, or if you set MYAPPDIR before running the application.
    To make it more reliable, the installer can itself create a wrapper script that
    sets MYAPPDIR and then runs the application. The user can be offered a choice of
    where to install the wrapper script, or it can be installed into a standard location,
    such as /usr/local/bin.

    Das hat mich erst mal recht geärgert, weil es doch irgenwie lächerlich ist, wenn sich mein Miniprogrämmchen in den Innereien vom System verwurzelt. Dann hab ich mir gedacht, nagut, schaun wir mal bei wxStandardPaths vorbei, um das Zeug doch an den "richtigen" Stellen zu speichern. Und siehe da:

    wxHelp schrieb:

    wxStandardPaths::GetExecutablePath
    wxString GetExecutablePath() const

    Return the directory and the filename for the current executable.

    Example return values:

    Unix: /usr/local/bin/exename
    Windows: C:\Programs\AppFolder\exename.exe
    Mac: /Programs/exename

    Öha. Eine Funktion ganz ohne Parameter. Einfach aufrufen. Und wo ist jetzt der Haken?

    Kann mich bitte jemand desillusionieren? 😉

    0
  • K

    Es gibt wirklich keinen Haken? Es funzt auf jeden System? Krass. 🙂

    0
  • P
    Mod

    Mir ist zumindest keiner bekannt.
    Es wird wohl auf jedenfall unter Windows und Linux funktionieren,
    wahrscheinlich auch auf Mac und Unix. Es ist ja auch nicht so schwer so eine
    Funktionalität zu implementieren, da fast alle Plattformen so eine Funktion nativ bieten.

    0
Anmelden zum Antworten