latex/wx/porting.tex

3 This addendum gives guidelines and tips for porting applications from
7 minimize porting time. The following sections detail the changes and
14 panel item layout, and the lack of automatic labels in some controls.
17 and will be supported by the user community for some time. And when you have
20 improved compilation speed, and many other enhancements. The revised architecture
33 Constraints should be the same in 2.0, and resources will be translated.
41 wxWindow::GetDC and definitely don't store wxDCs long-term
42 because in 2.0, you can't use GetDC() and wxDCs are not persistent.
48 2.0, these settings will only take effect between the construction and destruction
52 \item {\bf Don't use the wxCanvas member functions} that duplicate wxDC functions, such as SetPen and DrawLine, since
57 callback functions (and OnMenuCommand), and nearly all event handling will be done by functions taking a single event argument.
72 in most cases, and if you use wxString to receive strings returned from
79 Windows and X under wxWidgets 1.66. Yes, this is not easy... but I think it is better to conform to the
80 standards of each platform, and currently the size difference makes it difficult to
90 \item {\bf When creating a wxListBox}, put the wxLB\_SINGLE, wxLB\_MULTIPLE, wxLB\_EXTENDED styles in the window style parameter, and put
104 Instead of callbacks for panel items, menu command events, control commands and other events are directed to
110 frame class, add a DECLARE\_EVENT\_TABLE entry to the class, and then add an event table to
111 your implementation file, as a BEGIN\_EVENT\_TABLE and END\_EVENT\_TABLE block. The
129 (wxSizeEvent) and must again be `mapped' using the EVT\_SIZE macro. The same goes for all other events,
134 The class hierarchy has changed somewhat. wxToolBar and wxButtonBar
135 classes have been split into several classes, and are derived from wxControl (which was
143 There are new device context classes, with wxPanelDC and wxCanvasDC disappearing.
144 See \helpref{Device contexts and painting}{portingdc}.
150 and also means that management of the resource is largely automatic. You now pass {\it references} to
153 itself, but takes a copy of it (via reference counting), and the object's data gets freed up
159 pointers to GDI objects, and using the FindOrCreate... functions. However, it is preferable to
166 \section{Dialogs and controls}\label{portingdialogscontrols}
170 Most controls no longer have labels and values as they used to in 1.xx. Instead, labels
181 Windows now have integer identifiers; and position and size are now passed as wxPoint and
194 If you overrode or called {\bf wxDialog::Show}, use {\bf ShowModal} and test for a returned identifier,
201 \wxheading{wxText, wxMultiText and wxTextWindow}
203 These classes no longer exist and are replaced by the single class wxTextCtrl.
212 Bitmap messages are now a separate class, wxStaticBitmap, and wxMessage
222 instead, which takes standard dialogs and panels and associates controls with property objects.
224 and more flexible than using wxForm.
226 \section{Device contexts and painting}\label{portingdc}
229 they are accessed and constructed is a bit different.
231 You no longer use {\bf GetDC} to access device contexts for panels, dialogs and canvases.
243 that wxPoint now contains integer members, and there is a new class wxRealPoint. wxIntPoint
246 wxMetaFile and wxMetaFileDC have been renamed to wxMetafile and wxMetafileDC.
259 simplify your application's allocation and deallocation of memory for the returned string,
260 and simply assign the result to a wxString object. For example, replace this:
286 object, and for function arguments to denote that the object passed cannot be changed.
340 These are now separated out into wxDDEServer/Client/Connection (Windows only) and wxTCPServer/Client/Connection
341 (Windows and Unix). Take care to use wxString for your overridden function arguments, instead of char*, as per
347 using a different frame style. Please see the documentation for the MDI frame classes, and the MDI
353 and add an EVT\_ACTIVATE event table entry.
359 for your window, and the implementation of your function will need very few changes.
374 for your window, and the implementation of your function will need very few changes.
389 containing EVT\_MENU macros, and insert DECLARE\_EVENT\_TABLE() in your frame class, as
406 Replace the arguments with one wxSizeEvent\& argument, make it non-virtual, and add to your
414 DECLARE\_APP and IMPLEMENT\_APP as per the samples. Remove any occurrences of IMPLEMENT\_WXWIN\_MAIN:
427 Change the name to wxDialog, and for modal dialogs, use ShowModal instead of Show.
436 \helpref{Dialogs and controls}{portingdialogscontrols}
441 instead, or use .wxr files and validators.
445 The old wxPoint is called wxRealPoint, and wxPoint now uses integers.
464 of toolbar classes, with for example wxToolBar95, wxToolBarMSW and wxToolBarSimple classes existing
467 Toolbar management is supported by frames, so calling wxFrame::CreateToolBar and adding tools is usually
468 enough, and the SDI or MDI frame will manage the positioning for you. The client area of the frame is the space
469 left over when the menu bar, toolbar and status bar have been taken into account.