]>
Commit | Line | Data |
---|---|---|
15b6757b FM |
1 | ///////////////////////////////////////////////////////////////////////////// |
2 | // Name: platdetails.h | |
3 | // Purpose: Platform details page of the Doxygen manual | |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows license | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
9 | ||
10 | /*! | |
11 | ||
12 | @page platformdetails_page Platform details | |
13 | ||
14 | wxWidgets defines a common API across platforms, but uses the native graphical | |
15 | user interface (GUI) on each platform, so your program will take on the native | |
16 | look and feel that users are familiar with. Unfortunately native toolkits and | |
17 | hardware do not always support the functionality that the wxWidgets API | |
36c9828f | 18 | requires. This chapter collects notes about differences among supported platforms |
15b6757b FM |
19 | and ports. |
20 | ||
25c4a27c FM |
21 | @li @ref wxgtkport |
22 | @li @ref wxmacport | |
23 | @li @ref wxos2port | |
24 | @li @ref wxmglport | |
25 | @li @ref wxx11port | |
26 | @li @ref wxmswport | |
15b6757b FM |
27 | @li @ref nativedocs |
28 | ||
29 | ||
30 | <hr> | |
31 | ||
25c4a27c FM |
32 | |
33 | ||
34 | @section wxgtkport wxGTK port | |
35 | ||
36 | wxGTK is a port of wxWidgets using the GTK+ library. | |
37 | It makes use of GTK+'s native widgets wherever possible and uses | |
38 | wxWidgets' generic controls when needed. GTK+ itself has been | |
39 | ported to a number of systems, but so far only the original X11 | |
40 | version is supported. Support for other GTK+ backends is planned, | |
41 | such as the new DirectFB backend. | |
42 | ||
43 | All work is being done on GTK+ version 2.0 and above. Support for | |
44 | GTK+ 1.2 will be deprecated in a later release. | |
45 | ||
46 | You will need GTK+ 2.0 or higher which is available from: | |
47 | ||
48 | http://www.gtk.org | |
49 | ||
50 | The newer version of GTK+ you use, the more native widgets and | |
51 | features will be utilized. We have gone to a great extent to | |
52 | allow compiling wxWidgets applications with a latest version of | |
53 | GTK+, with the resulting binary working on systems even with a | |
54 | much lower version of GTK+. You will have to ensure that the | |
55 | application is launched with lazy symbol binding for that. | |
56 | ||
57 | In order to configure wxWidgets to compile wxGTK you will | |
58 | need use the @c --with-gtk argument to the @c configure script. | |
59 | This is the default for many systems. | |
60 | ||
61 | GTK+ 1.2 can still be used, albeit discouraged. For that you can | |
62 | pass @c --with-gtk=1 to the @c configure script. | |
63 | ||
64 | For further information, please see the files in docs/gtk | |
65 | in the distribution. | |
66 | ||
67 | ||
68 | ||
69 | ||
70 | @section wxmacport wxMac port | |
71 | ||
72 | wxMac is a port of wxWidgets for the Macintosh OS platform. | |
73 | Currently MacOS 8.6 or higher, MacOS 9.0 or higher and | |
74 | MacOS X 10.0 or higher are supported, although most development | |
75 | effort goes into MacOS X support. wxMac can be compiled both | |
76 | using Apple's developer tools and MetroWerks CodeWarrior in | |
77 | different versions. Support for MacOS 8.X and MacOS 9.X is | |
78 | only available through CodeWarrior. wxMac uses the Carbon | |
79 | API (and optionally the Classic API under MacOS 8.X). You | |
80 | will need wxWidgets version 2.3.3 or higher for a stable | |
81 | version of wxMac. | |
82 | ||
83 | For further information, please see the files in docs/mac | |
84 | in the distribution. | |
85 | ||
86 | ||
87 | ||
88 | ||
89 | @section wxmglport wxMGL port | |
90 | ||
91 | wxMGL is a port of wxWidgets using the MGL library available | |
92 | from SciTech as the underlying graphics backend. wxMGL draws | |
93 | its widgets using the wxUniversal widget set which is now | |
94 | part of wxWidgets. MGL itself runs on a variety of platforms | |
95 | including DOS, Linux hardware (similar to the Linux framebuffer) | |
96 | and various graphics systems such as Win32, X11 and OS/2. | |
97 | Note that currently MGL for Linux runs only on x86-based systems. | |
98 | ||
99 | You will need wxWidgets 2.3.3 or higher and MGL 5.0 or higher. | |
100 | The latter is available from | |
101 | ||
102 | http://www.scitechsoft.com/products/product_download.html | |
103 | ||
104 | In order to configure wxWidgets to compile wxMGL you will | |
105 | need to type: | |
106 | ||
107 | @verbatim configure --with-mgl --with-universal @endverbatim | |
108 | ||
109 | Under DOS, wxMGL uses a dmake based make system. | |
110 | ||
111 | For further information, please see the files in docs/mgl | |
112 | in the distribution. | |
113 | ||
114 | ||
115 | ||
116 | @section wxos2port wxOS2 port | |
117 | ||
118 | wxOS2 is a port of wxWidgets for the IBM OS/2 platform. | |
119 | It is currently under construction. | |
120 | ||
121 | ||
122 | ||
123 | @section wxx11port wxX11 port | |
124 | ||
125 | wxX11 is a port of wxWidgets using X11 (The X Window System) | |
126 | as the underlying graphics backend. wxX11 draws its widgets | |
127 | using the wxUniversal widget set which is now part of wxWidgets. | |
128 | wxX11 is well-suited for a number of special applications such | |
129 | as those running on systems with few resources (PDAs) or for | |
130 | applications which need to use a special themed look. You will need | |
131 | wxWidgets 2.3.2 or higher. | |
132 | ||
133 | In order to configure wxWidgets to compile wxX11 you will | |
134 | need to type: | |
135 | ||
136 | @verbatim configure --with-x11 --with-universal @endverbatim | |
137 | ||
138 | For further information, please see the files in docs/x11 | |
139 | in the distribution. There is also a page on the use of | |
140 | wxWidgets for embedded applications on the wxWidgets web site. | |
141 | ||
142 | ||
143 | ||
144 | ||
145 | ||
146 | @section wxmswport wxMSW port | |
147 | ||
148 | wxMSW is a port of wxWidgets for the Windows platforms | |
149 | including Windows 95, 98, ME, 2000, NT, XP in ANSI and | |
150 | Unicode mode (for Windows 95 through the MSLU extension | |
151 | library). wxMSW ensures native look and feel for XP | |
152 | as well when using wxWidgets version 2.3.3 or higher. | |
153 | wxMSW can be compile with a great variety of compilers | |
154 | including MS VC++, Borland 5.5, MinGW32, Cygwin and | |
155 | Watcom as well as cross-compilation with a Linux hosted | |
156 | MinGW32 tool chain. | |
157 | ||
158 | For further information, please see the files in docs/msw | |
159 | in the distribution. | |
160 | ||
161 | @subsection wxmswthemedborders Themed borders on Windows | |
162 | ||
163 | Starting with wxWidgets 2.8.5, you can specify the wxBORDER_THEME style to have wxWidgets | |
164 | use a themed border. Using the default XP theme, this is a thin 1-pixel blue border, | |
165 | with an extra 1-pixel border in the window client background colour (usually white) to | |
166 | separate the client area's scrollbars from the border. | |
167 | ||
168 | If you don't specify a border style for a wxTextCtrl in rich edit mode, wxWidgets now gives | |
169 | the control themed borders automatically, where previously they would take the Windows 95-style | |
170 | sunken border. Other native controls such as wxTextCtrl in non-rich edit mode, and wxComboBox, | |
171 | already paint themed borders where appropriate. To use themed borders on other windows, such | |
172 | as wxPanel, pass the wxBORDER_THEME style, or (apart from wxPanel) pass no border style. | |
173 | ||
174 | In general, specifying wxBORDER_THEME will cause a border of some kind to be used, chosen by the platform | |
175 | and control class. To leave the border decision entirely to wxWidgets, pass wxBORDER_DEFAULT. | |
176 | This is not to be confused with specifying wxBORDER_NONE, which says that there should | |
177 | definitely be @e no border. | |
178 | ||
179 | @subsubsection wxmswthemedborders_details More detail on border implementation | |
180 | ||
181 | The way that wxMSW decides whether to apply a themed border is as follows. | |
182 | The theming code calls wxWindow::GetBorder() to obtain a border. If no border style has been | |
183 | passed to the window constructor, GetBorder() calls GetDefaultBorder() for this window. | |
184 | If wxBORDER_THEME was passed to the window constructor, GetBorder() calls GetDefaultBorderForControl(). | |
185 | ||
186 | The implementation of wxWindow::GetDefaultBorder() on wxMSW calls wxWindow::CanApplyThemeBorder() | |
187 | which is a virtual function that tells wxWidgets whether a control can have a theme | |
188 | applied explicitly (some native controls already paint a theme in which case we should not | |
189 | apply it ourselves). Note that wxPanel is an exception to this rule because in many cases | |
190 | we wish to create a window with no border (for example, notebook pages). So wxPanel | |
191 | overrides GetDefaultBorder() in order to call the generic wxWindowBase::GetDefaultBorder(), | |
192 | returning wxBORDER_NONE. | |
193 | ||
194 | @subsection wxwince wxWinCE | |
195 | ||
196 | wxWinCE is the name given to wxMSW when compiled on Windows CE devices; | |
197 | most of wxMSW is common to Win32 and Windows CE but there are | |
198 | some simplifications, enhancements, and differences in | |
199 | behaviour. | |
200 | ||
201 | For building instructions, see docs/msw/wince in the | |
202 | distribution, also the section about Visual Studio 2005 project | |
203 | files below. The rest of this section documents issues you | |
204 | need to be aware of when programming for Windows CE devices. | |
205 | ||
206 | @subsubsection port_ General issues for wxWinCE programming | |
207 | ||
208 | Mobile applications generally have fewer features and | |
209 | simpler user interfaces. Simply omit whole sizers, static | |
210 | lines and controls in your dialogs, and use comboboxes instead | |
211 | of listboxes where appropriate. You also need to reduce | |
212 | the amount of spacing used by sizers, for which you can | |
213 | use a macro such as this: | |
214 | ||
215 | @verbatim | |
216 | #if defined(__WXWINCE__) | |
217 | #define wxLARGESMALL(large,small) small | |
218 | #else | |
219 | #define wxLARGESMALL(large,small) large | |
220 | #endif | |
221 | ||
222 | // Usage | |
223 | topsizer->Add( CreateTextSizer( message ), 0, wxALL, wxLARGESMALL(10,0) ); | |
224 | @endverbatim | |
225 | ||
226 | There is only ever one instance of a Windows CE application running, | |
227 | and wxWidgets will take care of showing the current instance and | |
228 | shutting down the second instance if necessary. | |
229 | ||
230 | You can test the return value of wxSystemSettings::GetScreenType() | |
231 | for a qualitative assessment of what kind of display is available, | |
232 | or use wxGetDisplaySize() if you need more information. | |
233 | ||
234 | You can also use wxGetOsVersion to test for a version of Windows CE at | |
235 | run-time (see the next section). However, because different builds | |
236 | are currently required to target different kinds of device, these | |
237 | values are hard-wired according to the build, and you cannot | |
238 | dynamically adapt the same executable for different major Windows CE | |
239 | platforms. This would require a different approach to the way | |
240 | wxWidgets adapts its behaviour (such as for menubars) to suit the | |
241 | style of device. | |
242 | ||
243 | See the "Life!" example (demos/life) for an example of | |
244 | an application that has been tailored for PocketPC and Smartphone use. | |
245 | ||
246 | @note don't forget to have this line in your .rc file, as for | |
247 | desktop Windows applications: | |
248 | ||
249 | @verbatim #include "wx/msw/wx.rc" @endverbatim | |
250 | ||
251 | @subsubsection port_ Testing for WinCE SDKs | |
252 | ||
253 | Use these preprocessor symbols to test for the different types of device or SDK: | |
254 | ||
255 | @li @b __SMARTPHONE__ Generic mobile devices with phone buttons and a small display | |
256 | @li @b __PDA__ Generic mobile devices with no phone | |
257 | @li @b __HANDHELDPC__ Generic mobile device with a keyboard | |
258 | @li @b __WXWINCE__ Microsoft-powered Windows CE devices, whether PocketPC, Smartphone or Standard SDK | |
259 | @li @b WIN32_PLATFORM_WFSP Microsoft-powered smartphone | |
260 | @li @b __POCKETPC__ Microsoft-powered PocketPC devices with touch-screen | |
261 | @li @b __WINCE_STANDARDSDK__ Microsoft-powered Windows CE devices, for generic Windows CE applications | |
262 | @li @b __WINCE_NET__ Microsoft-powered Windows CE .NET devices (_WIN32_WCE is 400 or greater) | |
263 | ||
264 | wxGetOsVersion will return these values: | |
265 | ||
266 | @li @b wxWINDOWS_POCKETPC The application is running under PocketPC. | |
267 | @li @b wxWINDOWS_SMARTPHONE The application is running under Smartphone. | |
268 | @li @b wxWINDOWS_CE The application is running under Windows CE (built with the Standard SDK). | |
269 | ||
270 | ||
271 | @subsubsection port_ Window sizing in wxWinCE | |
272 | ||
273 | Top level windows (dialogs, frames) are created always full-screen. Fit() of sizers will not rescale top | |
274 | level windows but instead will scale window content. | |
275 | ||
276 | If the screen orientation changes, the windows will automatically be resized | |
277 | so no further action needs to be taken (unless you want to change the layout | |
278 | according to the orientation, which you could detect in idle time, for example). | |
279 | When input panel (SIP) is shown, top level windows (frames and dialogs) resize | |
280 | accordingly (see wxTopLevelWindow::HandleSettingChange). | |
281 | ||
282 | @subsubsection port_ Closing top-level windows in wxWinCE | |
283 | ||
284 | You won't get a wxCloseEvent when the user clicks on the X in the titlebar | |
285 | on Smartphone and PocketPC; the window is simply hidden instead. However the system may send the | |
286 | event to force the application to close down. | |
287 | ||
288 | @subsubsection port_ Hibernation in wxWinCE | |
289 | ||
290 | Smartphone and PocketPC will send a wxEVT_HIBERNATE to the application object in low | |
291 | memory conditions. Your application should release memory and close dialogs, | |
292 | and wake up again when the next wxEVT_ACTIVATE or wxEVT_ACTIVATE_APP message is received. | |
293 | (wxEVT_ACTIVATE_APP is generated whenever a wxEVT_ACTIVATE event is received | |
294 | in Smartphone and PocketPC, since these platforms do not support WM_ACTIVATEAPP.) | |
295 | ||
296 | @subsubsection port_ Hardware buttons in wxWinCE | |
297 | ||
298 | Special hardware buttons are sent to a window via the wxEVT_HOTKEY event | |
299 | under Smartphone and PocketPC. You should first register each required button with | |
300 | wxWindow::RegisterHotKey, and unregister the button when you're done with it. For example: | |
301 | ||
302 | @verbatim | |
303 | win->RegisterHotKey(0, wxMOD_WIN, WXK_SPECIAL1); | |
304 | win->UnregisterHotKey(0); | |
305 | @endverbatim | |
306 | ||
307 | You may have to register the buttons in a wxEVT_ACTIVATE event handler | |
308 | since other applications will grab the buttons. | |
309 | ||
310 | There is currently no method of finding out the names of the special | |
311 | buttons or how many there are. | |
312 | ||
313 | @subsubsection port_ Dialogs in wxWinCE | |
314 | ||
315 | PocketPC dialogs have an OK button on the caption, and so you should generally | |
316 | not repeat an OK button on the dialog. You can add a Cancel button if necessary, but some dialogs | |
317 | simply don't offer you the choice (the guidelines recommend you offer an Undo facility | |
318 | to make up for it). When the user clicks on the OK button, your dialog will receive | |
319 | a wxID_OK event by default. If you wish to change this, call wxDialog::SetAffirmativeId | |
320 | with the required identifier to be used. Or, override wxDialog::DoOK (return @false to | |
321 | have wxWidgets simply call Close to dismiss the dialog). | |
322 | ||
323 | Smartphone dialogs do @e not have an OK button on the caption, and are closed | |
324 | using one of the two menu buttons. You need to assign these using wxTopLevelWindow::SetLeftMenu | |
325 | and wxTopLevelWindow::SetRightMenu, for example: | |
326 | ||
327 | @verbatim | |
328 | #ifdef __SMARTPHONE__ | |
329 | SetLeftMenu(wxID_OK); | |
330 | SetRightMenu(wxID_CANCEL, _("Cancel")); | |
331 | #elif defined(__POCKETPC__) | |
332 | // No OK/Cancel buttons on PocketPC, OK on caption will close | |
333 | #else | |
334 | topsizer->Add( CreateButtonSizer( wxOK|wxCANCEL ), 0, wxEXPAND | wxALL, 10 ); | |
335 | #endif | |
336 | @endverbatim | |
337 | ||
338 | For implementing property sheets (flat tabs), use a wxNotebook with wxNB_FLAT|wxNB_BOTTOM | |
339 | and have the notebook left, top and right sides overlap the dialog by about 3 pixels | |
340 | to eliminate spurious borders. You can do this by using a negative spacing in your | |
341 | sizer Add() call. The cross-platform property sheet dialog wxPropertySheetDialog is | |
342 | provided, to show settings in the correct style on PocketPC and on other platforms. | |
343 | ||
344 | Notifications (bubble HTML text with optional buttons and links) will also be | |
345 | implemented in the future for PocketPC. | |
346 | ||
347 | Modeless dialogs probably don't make sense for PocketPC and Smartphone, since | |
348 | frames and dialogs are normally full-screen, and a modeless dialog is normally | |
349 | intended to co-exist with the main application frame. | |
350 | ||
351 | @subsubsection port_menus_ppc Menubars and toolbars in PocketPC | |
352 | ||
353 | On PocketPC, a frame must always have a menubar, even if it's empty. | |
354 | An empty menubar/toolbar is automatically provided for dialogs, to hide | |
355 | any existing menubar for the duration of the dialog. | |
356 | ||
357 | Menubars and toolbars are implemented using a combined control, | |
358 | but you can use essentially the usual wxWidgets API; wxWidgets will combine the menubar | |
359 | and toolbar. However, there are some restrictions: | |
360 | ||
361 | @li You must create the frame's primary toolbar with wxFrame::CreateToolBar, | |
362 | because this uses the special wxToolMenuBar class (derived from wxToolBar) | |
363 | to implement the combined toolbar and menubar. Otherwise, you can create and manage toolbars | |
364 | using the wxToolBar class as usual, for example to implement an optional | |
365 | formatting toolbar above the menubar as Pocket Word does. But don't assign | |
366 | a wxToolBar to a frame using SetToolBar - you should always use CreateToolBar | |
367 | for the main frame toolbar. | |
368 | @li Deleting and adding tools to wxToolMenuBar after Realize is called is not supported. | |
369 | @li For speed, colours are not remapped to the system colours as they are | |
370 | in wxMSW. Provide the tool bitmaps either with the correct system button background, | |
371 | or with transparency (for example, using XPMs). | |
372 | @li Adding controls to wxToolMenuBar is not supported. However, wxToolBar supports | |
373 | controls. | |
374 | ||
375 | Unlike in all other ports, a wxDialog has a wxToolBar, automatically created | |
376 | for you. You may either leave it blank, or access it with wxDialog::GetToolBar | |
377 | and add buttons, then calling wxToolBar::Realize. You cannot set or recreate | |
378 | the toolbar. | |
379 | ||
380 | @subsubsection port_menus_smart Menubars and toolbars in Smartphone | |
381 | ||
382 | On Smartphone, there are only two menu buttons, so a menubar is simulated | |
383 | using a nested menu on the right menu button. Any toolbars are simply ignored on | |
384 | Smartphone. | |
385 | ||
386 | @subsubsection port_ Closing windows in wxWinCE | |
387 | ||
388 | The guidelines state that applications should not have a Quit menu item, | |
389 | since the user should not have to know whether an application is in memory | |
390 | or not. The close button on a window does not call the window's | |
391 | close handler; it simply hides the window. However, the guidelines say that | |
392 | the Ctrl+Q accelerator can be used to quit the application, so wxWidgets | |
393 | defines this accelerator by default and if your application handles | |
394 | wxID_EXIT, it will do the right thing. | |
395 | ||
396 | @subsubsection port_ Context menus in wxWinCE | |
397 | ||
398 | To enable context menus in PocketPC, you currently need to call wxWindow::EnableContextMenu, | |
399 | a wxWinCE-only function. Otherwise the context menu event (wxContextMenuEvent) will | |
400 | never be sent. This API is subject to change. | |
401 | ||
402 | Context menus are not supported in Smartphone. | |
403 | ||
404 | @subsubsection port_ Control differences on wxWinCE | |
405 | ||
406 | These controls and styles are specific to wxWinCE: | |
407 | ||
408 | @li wxTextCtrl The wxTE_CAPITALIZE style causes a CAPEDIT control to | |
409 | be created, which capitalizes the first letter. | |
410 | ||
411 | These controls are missing from wxWinCE: | |
412 | ||
413 | @li MDI classes MDI is not supported under Windows CE. | |
414 | @li wxMiniFrame Not supported under Windows CE. | |
415 | ||
416 | Tooltips are not currently supported for controls, since on PocketPC controls with | |
417 | tooltips are distinct controls, and it will be hard to add dynamic | |
418 | tooltip support. | |
419 | ||
420 | Control borders on PocketPC and Smartphone should normally be specified with | |
421 | wxBORDER_SIMPLE instead of wxBORDER_SUNKEN. Controls will usually adapt | |
422 | appropriately by virtue of their GetDefaultBorder() function, but if you | |
423 | wish to specify a style explicitly you can use wxDEFAULT_CONTROL_BORDER | |
424 | which will give a simple border on PocketPC and Smartphone, and the sunken border on | |
425 | other platforms. | |
426 | ||
427 | @subsubsection port_ Online help in wxWinCE | |
428 | ||
429 | You can use the help controller wxWinceHelpController which controls | |
430 | simple @c .htm files, usually installed in the Windows directory. | |
431 | See the Windows CE reference for how to format the HTML files. | |
432 | ||
433 | @subsubsection port_ Installing your PocketPC and Smartphone applications | |
434 | ||
435 | To install your application, you need to build a CAB file using | |
436 | the parameters defined in a special .inf file. The CabWiz program | |
437 | in your SDK will compile the CAB file from the .inf file and | |
438 | files that it specifies. | |
439 | ||
440 | For delivery, you can simply ask the user to copy the CAB file to the | |
441 | device and execute the CAB file using File Explorer. Or, you can | |
442 | write a program for the desktop PC that will find the ActiveSync | |
443 | Application Manager and install the CAB file on the device, | |
444 | which is obviously much easier for the user. | |
445 | ||
446 | Here are some links that may help. | |
447 | ||
448 | @li A setup builder that takes CABs and builds a setup program is at | |
449 | http://www.eskimo.com/~scottlu/win/index.html. | |
450 | @li Sample installation files can be found in | |
451 | <tt>Windows CE Tools/wce420/POCKET PC 2003/Samples/Win32/AppInst</tt>. | |
452 | @li An installer generator using wxPython can be found at | |
453 | http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html. | |
454 | @li Miscellaneous Windows CE resources can be found at | |
455 | http://www.orbworks.com/pcce/resources.html. | |
456 | @li Installer creation instructions with a setup.exe for installing to PPC can be found at | |
457 | http://www.pocketpcdn.com/articles/creatingsetup.html. | |
458 | @li Microsoft instructions are at | |
459 | http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true | |
460 | @li Troubleshooting WinCE application installations: | |
461 | http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007 | |
462 | ||
463 | You may also check out <tt>demos/life/setup/wince</tt> which contains | |
464 | scripts to create a PocketPC installation for ARM-based | |
465 | devices. In particular, @c build.bat builds the distribution and | |
466 | copies it to a directory called @c Deliver. | |
467 | ||
468 | @subsubsection port_ wxFileDialog in PocketPC | |
469 | ||
470 | Allowing the user to access files on memory cards, or on arbitrary | |
471 | parts of the filesystem, is a pain; the standard file dialog only | |
472 | shows folders under My Documents or folders on memory cards | |
473 | (not the system or card root directory, for example). This is | |
474 | a known problem for PocketPC developers. | |
475 | ||
476 | If you need a file dialog that allows access to all folders, | |
477 | you can use wxGenericFileDialog instead. You will need to include | |
478 | @c wx/generic/filedlgg.h. | |
479 | ||
480 | @subsubsection port_ Embedded Visual C++ Issues | |
481 | ||
482 | <b>Run-time type information</b> | |
483 | ||
484 | If you wish to use runtime type information (RTTI) with eVC++ 4, you need to download | |
485 | an extra library, @c ccrtrtti.lib, and link with it. At the time of | |
486 | writing you can get it from here: | |
487 | ||
488 | @verbatim | |
489 | http://support.microsoft.com/kb/830482/en-us | |
490 | @endverbatim | |
491 | ||
492 | Otherwise you will get linker errors similar to this: | |
493 | ||
494 | @verbatim | |
495 | wxwince26d.lib(control.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@) | |
496 | @endverbatim | |
497 | ||
498 | <b>Windows Mobile 5.0 emulator</b> | |
499 | ||
500 | Note that there is no separate emulator configuration for Windows Mobile 5.0: the | |
501 | emulator runs the ARM code directly. | |
502 | ||
503 | <b>Visual Studio 2005 project files</b> | |
504 | ||
505 | Unfortunately, Visual Studio 2005, required to build Windows Mobile 5.0 applications, | |
506 | doesn't do a perfect job of converting the project files from eVC++ format. | |
507 | ||
508 | When you have converted the wxWidgets workspace, edit the configuration properties | |
a3465294 | 509 | for each configuration and in the Librarian, add a relative path ..\\..\\lib to |
25c4a27c | 510 | each library path. For example: |
a3465294 | 511 | <tt>..\\$(PlatformName)\\$(ConfigurationName)\\wx_mono.lib</tt>. |
25c4a27c FM |
512 | |
513 | Then, for a sample you want to compile, edit the configuration properties | |
514 | and make sure | |
a3465294 | 515 | <tt>..\\..\\lib\\$(PlatformName)\\$(ConfigurationName)</tt> |
25c4a27c FM |
516 | is in the Linker/General/Additional Library Directories property. |
517 | Also change the Linker/Input/Additional Dependencies property to something like | |
518 | <tt>coredll.lib wx_mono.lib wx_wxjpeg.lib wx_wxpng.lib wx_wxzlib.lib wx_wxexpat.lib | |
519 | commctrl.lib winsock.lib wininet.lib</tt> | |
520 | (since the library names in the wxWidgets workspace were changed by VS 2005). | |
521 | ||
522 | Alternately, you could could edit all the names to be identical to the original eVC++ | |
523 | names, but this will probably be more fiddly. | |
524 | ||
525 | @subsubsection port_ Remaining issues | |
526 | ||
527 | These are some of the remaining problems to be sorted out, and features | |
528 | to be supported. | |
529 | ||
530 | @li <b>Windows Mobile 5 issues.</b> It is not possible to get the HMENU for | |
531 | the command bar on Mobile 5, so the menubar functions need to be rewritten | |
532 | to get the individual menus without use of a menubar handle. Also the | |
533 | new Mobile 5 convention of using only two menus (and no bitmap buttons) needs to be | |
534 | considered. | |
535 | @li <b>Sizer speed.</b> Particularly for dialogs containing notebooks, | |
536 | layout seems slow. Some analysis is required. | |
537 | @li <b>Notification boxes.</b> The balloon-like notification messages, and their | |
538 | icons, should be implemented. This will be quite straightforward. | |
539 | @li <b>SIP size.</b> We need to be able to get the area taken up by the SIP (input panel), | |
540 | and the remaining area, by calling SHSipInfo. We also may need to be able to show and hide | |
541 | the SIP programmatically, with SHSipPreference. See also the <em>Input Dialogs</em> topic in | |
542 | the <em>Programming Windows CE</em> guide for more on this, and how to have dialogs | |
543 | show the SIP automatically using the WC_SIPREF control. | |
544 | @li <b>wxStaticBitmap.</b> The About box in the "Life!" demo shows a bitmap that is | |
545 | the correct size on the emulator, but too small on a VGA Pocket Loox device. | |
546 | @li <b>wxStaticLine.</b> Lines don't show up, and the documentation suggests that | |
547 | missing styles are implemented with WM_PAINT. | |
548 | @li <b>HTML control.</b> PocketPC has its own HTML control which can be used for showing | |
549 | local pages or navigating the web. We should create a version of wxHtmlWindow that uses this | |
550 | control, or have a separately-named control (wxHtmlCtrl), with a syntax as close as possible | |
551 | to wxHtmlWindow. | |
552 | @li <b>Tooltip control.</b> PocketPC uses special TTBUTTON and TTSTATIC controls for adding | |
553 | tooltips, with the tooltip separated from the label with a double tilde. We need to support | |
554 | this using SetToolTip.(Unfortunately it does not seem possible to dynamically remove the tooltip, | |
555 | so an extra style may be required.) | |
556 | @li <b>Focus.</b> In the wxPropertySheetDialog demo on Smartphone, it's not possible to navigate | |
557 | between controls. The focus handling in wxWidgets needs investigation. See in particular | |
558 | src/common/containr.cpp, and note that the default OnActivate handler in src/msw/toplevel.cpp | |
559 | sets the focus to the first child of the dialog. | |
560 | @li <b>OK button.</b> We should allow the OK button on a dialog to be optional, perhaps | |
561 | by using wxCLOSE_BOX to indicate when the OK button should be displayed. | |
562 | @li <b>Dynamic adaptation.</b> We should probably be using run-time tests more | |
563 | than preprocessor tests, so that the same WinCE application can run on different | |
564 | versions of the operating system. | |
565 | @li <b>Modeless dialogs.</b> When a modeless dialog is hidden with the OK button, it doesn't restore the | |
566 | frame's menubar. See for example the find dialog in the dialogs sample. However, the menubar is restored | |
567 | if pressing Cancel (the window is closed). This reflects the fact that modeless dialogs are | |
568 | not very useful on Windows CE; however, we could perhaps destroy/restore a modeless dialog's menubar | |
569 | on deactivation and activation. | |
570 | @li <b>Home screen plugins.</b> Figure out how to make home screen plugins for use with wxWidgets | |
571 | applications (see http://www.codeproject.com/ce/CTodayWindow.asp for inspiration). | |
572 | Although we can't use wxWidgets to create the plugin (too large), we could perhaps write | |
573 | a generic plugin that takes registry information from a given application, with | |
574 | options to display information in a particular way using icons and text from | |
575 | a specified location. | |
576 | @li <b>Further abstraction.</b> We should be able to abstract away more of the differences | |
577 | between desktop and mobile applications, in particular for sizer layout. | |
578 | @li <b>Dialog captions.</b> The blue, bold captions on dialogs - with optional help button - | |
579 | should be catered for, either by hard-wiring the capability into all dialogs and panels, | |
580 | or by providing a standard component and sizer. | |
36c9828f | 581 | |
15b6757b FM |
582 | |
583 | @section nativedocs Documentation for the native toolkits | |
36c9828f | 584 | |
15b6757b FM |
585 | It's sometimes useful to interface directly with the underlying toolkit |
586 | used by wxWidgets to e.g. use toolkit-specific features. | |
587 | In such case (or when you want to e.g. write a port-specific patch) it can be | |
588 | necessary to use the underlying toolkit API directly: | |
36c9828f | 589 | |
15b6757b FM |
590 | @li wxMSW port uses win32 API: see MSDN docs at http://msdn2.microsoft.com/en-us/library/ms649779.aspx |
591 | @li wxGTK port uses GTK+: see GTK+ 2.x docs at http://developer.gnome.org/doc/API/2.0/gtk/index.html | |
592 | ||
593 | */ |