dkwxwiz manual

Authors:

dkwxwiz — Start new wxWidgets + libdk4 project

dkwxwiz — Start new wxWidgets + libdk4 project

Synopsis

dkwxwiz [_options_] _program_ _application_ _frame_

Command line argument	Purpose
program	Name of the executable program to produce, without any dot.
application	Name of the application class derived from wxApp.
frame	Name of the main window class derived from wxFrame.

All three names are used in C identifiers, so they must be valid C identifiers theirselves (character or underscore, optionally followed by a sequence of character, underscore or digits).

Description

The dkwxwiz program produces a code skeleton for an application using the wxWidgets libraries and the DK tools libraries.
You can use this wizard to start a new project.

Options

Option	Argument type	Purpose
-c	Text	Name of the copyright owner
-l	String	License to use, i.e. "bsd"
-f		Force program to write outupt files, even if the output files already exist.
-h		Show help text.
-v		Show version information.
-L		Show license information.

Exit status

0 on success, all other status codes indicate an error.

Files

The following template files are used:

dkwxwizh.txt
Template for the header file used by all modules.

dkwxwiza.txt
Template for the application class derived from wxApp.

dkwxwizf.txt
Template for the main window class derived from wxFrame.

dkwxwizc.txt
Template for the configure.ac script, used in Linux/Unix build process.

dkwxwizm.txt
Template for the Makefile.in file, used in Linux/Unix build process.

dkwxwizv.txt
Template for the makefile.vc file, used in Windows builds.

dkwxwizr.txt
Template for the application *.rc file, used in Windows builds.

dkwxwizx.txt
Template for the *.xpm application icon file.

The reverse search order for configuration files is used, application name "dkwxwiz", application group name "dktools".

Restrictions

To configure all settings via command line would require many options. So you should edit all the files generated by dkwxwiz and apply changes to places marked by __CHANGE__ if necessary before doing the first build.

Notes

This program uses DK libraries version 3.

Example / Tutorial

Run the wizard

Prepare a new empty directory and run:

dkwxwiz testprog TestApp TestFrame

The command generates the following files:

testprog.h
Header file for the project.

TestApp.cpt
Source code for the application class.

TestFrame.wxc
Source code for the top level window class.

testprog.xpm
Program icon for non-Windows systems.

Makefile.in
Used by configure to create the Makefile.

configure.ac
Input file for autoconf.

makefile.vc
Makefile for Windows.

testprog.rc
Resource file for windows build. This file references the icon and contains some information.

Build process on Linux, Unix

Run

dkcpre -l
autoconf
./configure
make

to build the initial version.

The dkcpre command generates TestApp.h and TestApp.cpp from TestApp.cpt and TestFrame.h and TestFrame.cpp from TestFrame.wxc.
Additionally it creates the testprog.str file containing a string table in English. The file is re-generated on each run of dkcpre.

The autoconf command generates a configure script from configure.ac.

The configure script uses "wx-config" to find the libraries to use and the library paths. Additionally it sets up some C/C++ compiler options.

The final make command builds the testprog application. You can run it using:

./testprog

Build process on Windows

Edit the makefile.vc file and apply modifications if necessary.

Edit the testprog.rc file and apply modifications if necessary.

In a cmd.exe window set up the paths for Visual Studio and/or platform SDK and run:

dkcpre -l
nmake -f makefile.vc

How to continue

Places of interest are marked by __CHANGE__ number comments.

It is a good idea to edit all the files just created directly after running dkwxwiz. Use your editors search feature to visit all places marked by __CHANGE__.

Change number	Title	File(s)	How to modify
001	Copyright holder	TestApp.cpt TestFrame.wxc	Enter the name of the copyright owner here (i.e. the name for private persons doing spare time projects, the company name for commercial software vendors).
002	License type	TestApp.cpt TestFrame.wxc	Correct the license type. You can use "bsd", "gpl", "lgpl", or "commercial" here.
003	Copyright year	TestApp.cpt TestFrame.wxc	Correct the years used in the copyright.
004	Program name	TestApp.cpt	Correct the program name if necessary.
005	Program version	TestApp.cpt	Correct the program version if necessary.
006	Program group	TestApp.cpt	Correct the program group name if necessary. The program group name is used when searching for resource files.
007	Software vendor	TestApp.cpt	Correct the software vendor name. This name must not contain any whitespaces, it is used to save and retrieve configuration data.
008	Idle processing	TestFrame.wxc	If no idle event processing is required, remove the OnIdle() handler function declaration in the class definition, the implementation, and the event table entry.
009	Further application class members	TestApp.cpt	If you add further members to the application class, you must initialize them and set them up in the OnInit() method and release resources allocated by the members in the OnExit() method. If member initialization in OnInit() fails for some reason, use "goto finished;" so the end of function is reached without setting the return code to true.
010	Exit status code	TestApp.cpt	The exit status code of the application is the result of the OnExit() method.
011	Further window class members	TestFrame.wxc	If you add further members to the window class, you must initialize them and set them up in the "constructor start" section. If initialization fails, use goto dkctGUILayoutFinished; to jump to the end of the constructor without setting the success indicator. Use the destructor to release resources allocated by member variables.
012	Further local variables in the constructor	TestFrame.wxc	If you need further local variables in the constructor, declare and initialize them in the "constructor start" section. In the "constructor end" section you can release resources allocated by the local variables.
013	Unsaved data	TestFrame.wxc	In the canClose() function you should check for unsaved data before returning. Return true if the window can be closed, false otherwise.
014	Top-level window methods	TestFrame.wxc	You can add further methods to the top-level window class.
015	GUI	TestFrame.wxc TestApp.cpt	You can remove the lDummy element from the contentsSizer and fill the contentsSizer with GUI elements as needed. When removing the lDummy object, you can reuse text 11 in the textprog_texts array for other GUI elements.
016	Localized texts	TestApp.cpt	You can add further texts to the textprog_texts array. These texts — or the corresponding translations — are available in the sTexts array of the TestFrame class.
017	Top-level window class events	TestFrame.wxc testprog.h	Define event IDs for new events in the testprog.h file, declare the handlers in the top-level window class, configure event handling in the event table, and provide the implementation.
018	Classes and modules	testprog.h Makefile.in	To use more classes and modules add #include-instructions to the testprog.h file. For classes showing a GUI use a .wxc file, for other modules use a .cpt or *.ctr file. The testprog.h file should be included by all modules in the project, this file in turn includes all headers needed. In Makefile.in add object modules to OBJ_testprog, add libraries to the linker instruction building the testprog program.
019	About dialog box	TestFrame.wxc	You might want to change the "About" dialog box to be more informative.

You should create the following files:

File	Purpose
testprog.chm	Help file for use on Windows systems.
testprog.htb	Help file for use on non-Windows systems.
testprog.ico	Application icon used on Windows systems.
testprog.xpm	Application icon used on non-Windows systems.

dktools - Dirk Krauses tools Wiki

Drawing, graphics conversion, software development, administration.