## 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.