Cross-Platform GUI Programming with wxWidgets
|
Passing commands to the application to be read on initialization is often useful, and if the application is document-oriented, you should allow files to be loaded in this way. You also might want to let the application be run from the operating system command line, for example to automate tasks from a makefile, in which case command-line options can be used to tell the application that it should be run without a user interface. Although most configuration of an application will be done via the user interface, command-line configuration options can be appropriate in some cases, such as turning on a debug mode. wxWidgets provides the wxCmdLineParser class to make this programming task quite easy, avoiding the need to process wxApp::argc and wxApp::argv directly. The class looks for switches (such as -verbose), options (such as-debug:1), and parameters (such as "myfile.txt"). It can recognize both short and long forms of switches and options, and each item can have a help string, which will be used by Usage when writing help text to the current log target. Here's an example, showing how to parse switches, options, and parameters: [View full width] #include "wx/cmdline.h" static const wxCmdLineEntryDesc g_cmdLineDesc[] = { { wxCMD_LINE_SWITCH, wxT("h"), wxT("help"), wxT("displays help on the command lineThe use of wxFileName for normalizing the file name is necessary because Windows sometimes passes the short form when the application is invoked from the command line. As we noted earlier in the chapter, Mac OS X doesn't use the command line when running an application by opening an associated document; instead, wxApp::MacOpenFile is called after the application has initialized. However, the command-line method is used by other operating systems. If you intend to write a document-based application for Mac OS X and other operating systems, you should allow for both methods. |
|