Contents Up Previous Next

Windows-specific files

wxWindows application compilation under MS Windows requires at least two extra files, resource and module definition files.

Resource file
Module definition file
Allocating and deleting wxWindows objects


Resource file

The least that must be defined in the Windows resource file (extension RC) is the following statement:

rcinclude "wx/msw/wx.rc"
which includes essential internal wxWindows definitions. The resource script may also contain references to icons, cursors, etc., for example:

wxicon icon wx.ico
The icon can then be referenced by name when creating a frame icon. See the MS Windows SDK documentation.


Note: include wx.rc after any ICON statements so programs that search your executable for icons (such as the Program Manager) find your application icon first.


Module definition file

A module definition file (extension DEF) is required for 16-bit applications, and looks like the following:

NAME         Hello
DESCRIPTION  'Hello'
EXETYPE      WINDOWS
STUB         'WINSTUB.EXE'
CODE         PRELOAD MOVEABLE DISCARDABLE
DATA         PRELOAD MOVEABLE MULTIPLE
HEAPSIZE     1024
STACKSIZE    8192
The only lines which will usually have to be changed per application are NAME and DESCRIPTION.


Allocating and deleting wxWindows objects

In general, classes derived from wxWindow must dynamically allocated with new and deleted with delete. If you delete a window, all of its children and descendants will be automatically deleted, so you don't need to delete these descendants explicitly.

When deleting a frame or dialog, use Destroy rather than delete so that the wxWindows delayed deletion can take effect. This waits until idle time (when all messages have been processed) to actually delete the window, to avoid problems associated with the GUI sending events to deleted windows.

Don't create a window on the stack, because this will interfere with delayed deletion.

If you decide to allocate a C++ array of objects (such as wxBitmap) that may be cleaned up by wxWindows, make sure you delete the array explicitly before wxWindows has a chance to do so on exit, since calling delete on array members will cause memory problems.

wxColour can be created statically: it is not automatically cleaned up and is unlikely to be shared between other objects; it is lightweight enough for copies to be made.

Beware of deleting objects such as a wxPen or wxBitmap if they are still in use. Windows is particularly sensitive to this: so make sure you make calls like wxDC::SetPen(wxNullPen) or wxDC::SelectObject(wxNullBitmap) before deleting a drawing object that may be in use. Code that doesn't do this will probably work fine on some platforms, and then fail under Windows.