Storing Application Resources

A simple application might consist of no more than an executable, but more realistically, you'll have a help file, maybe HTML files and images, and application-specific data files. Where do these things go?

Reducing the Number of Data Files

You can do several things to create a more tidy installation. Firstly, you can include XPM images in your C++ files (with #include) instead of loading them from disk. Secondly, if you are using XRC files, you can compile them into C++ using the wxrc utility in utils/wxrc in your wxWidgets distribution:

 wxrc resources.xrc --verbose --cpp-code --output resources.cpp 

You can then call the InitXmlResource function defined in the generated C++ file to load the resources.

Thirdly, you can archive your data files into a standard zip file and extract them using streams and virtual file systems, as explained in for data files. Include "wx/fileloc.h" and then call the class's static functions, including GetConfigDir, GetInstallDir, GeTDataDir, GetLocalDataDir, and GetUserConfig Data. Refer to the wxWidgets manual for details of these functions' return values on each platform.

On Mac OS X, you'll need to create an application bundle: a file hierarchy with standard locations for the executable, data files, and so on. See later in the chapter for information on creating a bundle.

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.