Preparing for version 2.0
Even before compiling with version 2.0, there's also a lot you can do right now to make porting
relatively simple. Here are a few tips.
- Use constraints or .wxr resources for layout, rather than the default layout scheme.
Constraints should be the same in 2.0, and resources will be translated.
- Use separate wxMessage items instead of labels for wxText, wxMultiText,
wxChoice, wxComboBox. These labels will disappear in 2.0. Use separate
wxMessages whether you're creating controls programmatically or using
the dialog editor. The future dialog editor will be able to translate
from old to new more accurately if labels are separated out.
- Parameterise functions that use wxDC or derivatives, i.e. make the wxDC
an argument to all functions that do drawing. Minimise the use of
wxWindow::GetDC and definitely don't store wxDCs long-term
because in 2.0, you can't use GetDC() and wxDCs are not persistent.
You will use wxClientDC, wxPaintDC stack objects instead. Minimising
the use of GetDC() will ensure that there are very few places you
have to change drawing code for 2.0.
- Don't set GDI objects (wxPen, wxBrush etc.) in windows or wxCanvasDCs before they're
needed (e.g. in constructors) - do so within your drawing routine instead. In
2.0, these settings will only take effect between the construction and destruction
of temporary wxClient/PaintDC objects.
- Don't rely on arguments to wxDC functions being floating point - they will
be 32-bit integers in 2.0.
- Don't use the wxCanvas member functions that duplicate wxDC functions, such as SetPen and DrawLine, since
they are going.
- Using member callbacks called from global callback functions will make the transition
easier - see the FAQ
for some notes on using member functions for callbacks. wxWindows 2.0 will banish global
callback functions (and OnMenuCommand), and nearly all event handling will be done by functions taking a single event argument.
So in future you will have code like:
void MyFrame::OnOK(wxCommandEvent&event)
...
You may find that writing the extra code to call a member function isn't worth it at this stage,
but the option is there.
- Use wxString wherever possible. 2.0 replaces char * with wxString
in most cases, and if you use wxString to receive strings returned from
wxWindows functions (except when you need to save the pointer if deallocation is required), there should
be no conversion problems later on.
- Be aware that under Windows, font sizes will change to match standard Windows
font sizes (for example, a 12-point font will appear bigger than before). Write your application
to be flexible where fonts are concerned.
Don't rely on fonts being similarly-sized across platforms, as they were (by chance) between
Windows and X under wxWindows 1.66. Yes, this is not easy... but I think it is better to conform to the
standards of each platform, and currently the size difference makes it difficult to
conform to Windows UI standards. You may eventually wish to build in a global 'fudge-factor' to compensate
for size differences. The old font sizing will still be available via wx_setup.h, so do not panic...
- Consider dropping wxForm usage:
wxPropertyFormView can be used in a wxForm-like way, except that you specify a pre-constructed panel
or dialog; or you can use a wxPropertyListView to show attributes in a scrolling list - you don't even need
to lay panel items out.
Because wxForm uses a number of features to be dropped in wxWindows 2.0, it cannot be
supported in the future, at least in its present state.
- When creating a wxListBox, put the wxLB_SINGLE, wxLB_MULTIPLE, wxLB_EXTENDED styles in the window style parameter, and put
zero in the multiple parameter. The multiple parameter will be removed in 2.0.
- For MDI applications, don't reply on MDI being run-time-switchable in the way that the
MDI sample is. In wxWindows 2.0, MDI functionality is separated into distinct classes.