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