| 1 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
| 2 | %% Name: wxmsw.tex |
| 3 | %% Purpose: wxMSW and wxWinCE platform specific informations |
| 4 | %% Author: wxWidgets Team |
| 5 | %% Modified by: |
| 6 | %% Created: |
| 7 | %% RCS-ID: $Id$ |
| 8 | %% Copyright: (c) wxWidgets Team |
| 9 | %% License: wxWindows license |
| 10 | %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% |
| 11 | |
| 12 | \section{wxMSW port}\label{wxmswport} |
| 13 | |
| 14 | wxMSW is a port of wxWidgets for the Windows platforms |
| 15 | including Windows 95, 98, ME, 2000, NT, XP in ANSI and |
| 16 | Unicode mode (for Windows 95 through the MSLU extension |
| 17 | library). wxMSW ensures native look and feel for XP |
| 18 | as well when using wxWidgets version 2.3.3 or higher. |
| 19 | wxMSW can be compile with a great variety of compilers |
| 20 | including MS VC++, Borland 5.5, MinGW32, Cygwin and |
| 21 | Watcom as well as cross-compilation with a Linux hosted |
| 22 | MinGW32 tool chain. |
| 23 | |
| 24 | For further information, please see the files in docs/msw |
| 25 | in the distribution. |
| 26 | |
| 27 | \subsection{wxWinCE}\label{wxwince} |
| 28 | |
| 29 | wxWinCE is the name given to wxMSW when compiled on Windows CE devices; |
| 30 | most of wxMSW is common to Win32 and Windows CE but there are |
| 31 | some simplifications, enhancements, and differences in |
| 32 | behaviour. |
| 33 | |
| 34 | For building instructions, see docs/msw/wince in the |
| 35 | distribution, also the section about Visual Studio 2005 project |
| 36 | files below. The rest of this section documents issues you |
| 37 | need to be aware of when programming for Windows CE devices. |
| 38 | |
| 39 | \subsubsection{General issues for wxWinCE programming} |
| 40 | |
| 41 | Mobile applications generally have fewer features and |
| 42 | simpler user interfaces. Simply omit whole sizers, static |
| 43 | lines and controls in your dialogs, and use comboboxes instead |
| 44 | of listboxes where appropriate. You also need to reduce |
| 45 | the amount of spacing used by sizers, for which you can |
| 46 | use a macro such as this: |
| 47 | |
| 48 | \begin{verbatim} |
| 49 | #if defined(__WXWINCE__) |
| 50 | #define wxLARGESMALL(large,small) small |
| 51 | #else |
| 52 | #define wxLARGESMALL(large,small) large |
| 53 | #endif |
| 54 | |
| 55 | // Usage |
| 56 | topsizer->Add( CreateTextSizer( message ), 0, wxALL, wxLARGESMALL(10,0) ); |
| 57 | \end{verbatim} |
| 58 | |
| 59 | There is only ever one instance of a Windows CE application running, |
| 60 | and wxWidgets will take care of showing the current instance and |
| 61 | shutting down the second instance if necessary. |
| 62 | |
| 63 | You can test the return value of wxSystemSettings::GetScreenType() |
| 64 | for a qualitative assessment of what kind of display is available, |
| 65 | or use wxGetDisplaySize() if you need more information. |
| 66 | |
| 67 | You can also use wxGetOsVersion to test for a version of Windows CE at |
| 68 | run-time (see the next section). However, because different builds |
| 69 | are currently required to target different kinds of device, these |
| 70 | values are hard-wired according to the build, and you cannot |
| 71 | dynamically adapt the same executable for different major Windows CE |
| 72 | platforms. This would require a different approach to the way |
| 73 | wxWidgets adapts its behaviour (such as for menubars) to suit the |
| 74 | style of device. |
| 75 | |
| 76 | See the "Life!" example (demos/life) for an example of |
| 77 | an application that has been tailored for PocketPC and Smartphone use. |
| 78 | |
| 79 | {\bf Note:} don't forget to have this line in your .rc file, as for |
| 80 | desktop Windows applications: |
| 81 | |
| 82 | \begin{verbatim} |
| 83 | #include "wx/msw/wx.rc" |
| 84 | \end{verbatim} |
| 85 | |
| 86 | \subsubsection{Testing for WinCE SDKs} |
| 87 | |
| 88 | Use these preprocessor symbols to test for the different types of device or SDK: |
| 89 | |
| 90 | \begin{twocollist}\itemsep=0pt |
| 91 | \twocolitem{\_\_SMARTPHONE\_\_}{Generic mobile devices with phone buttons and a small display} |
| 92 | \twocolitem{\_\_PDA\_\_}{Generic mobile devices with no phone} |
| 93 | \twocolitem{\_\_HANDHELDPC\_\_}{Generic mobile device with a keyboard} |
| 94 | \twocolitem{\_\_WXWINCE\_\_}{Microsoft-powered Windows CE devices, whether PocketPC, Smartphone or Standard SDK} |
| 95 | \twocolitem{WIN32\_PLATFORM\_WFSP}{Microsoft-powered smartphone} |
| 96 | \twocolitem{\_\_POCKETPC\_\_}{Microsoft-powered PocketPC devices with touch-screen} |
| 97 | \twocolitem{\_\_WINCE\_STANDARDSDK\_\_}{Microsoft-powered Windows CE devices, for generic Windows CE applications} |
| 98 | \twocolitem{\_\_WINCE\_NET\_\_}{Microsoft-powered Windows CE .NET devices (\_WIN32\_WCE is 400 or greater)} |
| 99 | \end{twocollist} |
| 100 | |
| 101 | wxGetOsVersion will return these values: |
| 102 | |
| 103 | \begin{twocollist}\itemsep=0pt |
| 104 | \twocolitem{wxWINDOWS\_POCKETPC}{The application is running under PocketPC.} |
| 105 | \twocolitem{wxWINDOWS\_SMARTPHONE}{The application is running under Smartphone.} |
| 106 | \twocolitem{wxWINDOWS\_CE}{The application is running under Windows CE (built with the Standard SDK).} |
| 107 | \end{twocollist} |
| 108 | |
| 109 | \subsubsection{Window sizing in wxWinCE} |
| 110 | |
| 111 | Top level windows (dialogs, frames) are created always full-screen. Fit() of sizers will not rescale top |
| 112 | level windows but instead will scale window content. |
| 113 | |
| 114 | If the screen orientation changes, the windows will automatically be resized |
| 115 | so no further action needs to be taken (unless you want to change the layout |
| 116 | according to the orientation, which you could detect in idle time, for example). |
| 117 | When input panel (SIP) is shown, top level windows (frames and dialogs) resize |
| 118 | accordingly (see \helpref{wxTopLevelWindow::HandleSettingChange}{wxtoplevelwindowhandlesettingchange}). |
| 119 | |
| 120 | \subsubsection{Closing top-level windows in wxWinCE} |
| 121 | |
| 122 | You won't get a wxCloseEvent when the user clicks on the X in the titlebar |
| 123 | on Smartphone and PocketPC; the window is simply hidden instead. However the system may send the |
| 124 | event to force the application to close down. |
| 125 | |
| 126 | \subsubsection{Hibernation in wxWinCE} |
| 127 | |
| 128 | Smartphone and PocketPC will send a wxEVT\_HIBERNATE to the application object in low |
| 129 | memory conditions. Your application should release memory and close dialogs, |
| 130 | and wake up again when the next wxEVT\_ACTIVATE or wxEVT\_ACTIVATE\_APP message is received. |
| 131 | (wxEVT\_ACTIVATE\_APP is generated whenever a wxEVT\_ACTIVATE event is received |
| 132 | in Smartphone and PocketPC, since these platforms do not support WM\_ACTIVATEAPP.) |
| 133 | |
| 134 | \subsubsection{Hardware buttons in wxWinCE} |
| 135 | |
| 136 | Special hardware buttons are sent to a window via the wxEVT\_HOTKEY event |
| 137 | under Smartphone and PocketPC. You should first register each required button with \helpref{wxWindow::RegisterHotKey}{wxwindowregisterhotkey}, |
| 138 | and unregister the button when you're done with it. For example: |
| 139 | |
| 140 | \begin{verbatim} |
| 141 | win->RegisterHotKey(0, wxMOD_WIN, WXK_SPECIAL1); |
| 142 | win->UnregisterHotKey(0); |
| 143 | \end{verbatim} |
| 144 | |
| 145 | You may have to register the buttons in a wxEVT\_ACTIVATE event handler |
| 146 | since other applications will grab the buttons. |
| 147 | |
| 148 | There is currently no method of finding out the names of the special |
| 149 | buttons or how many there are. |
| 150 | |
| 151 | \subsubsection{Dialogs in wxWinCE} |
| 152 | |
| 153 | PocketPC dialogs have an OK button on the caption, and so you should generally |
| 154 | not repeat an OK button on the dialog. You can add a Cancel button if necessary, but some dialogs |
| 155 | simply don't offer you the choice (the guidelines recommend you offer an Undo facility |
| 156 | to make up for it). When the user clicks on the OK button, your dialog will receive |
| 157 | a wxID\_OK event by default. If you wish to change this, call \helpref{wxDialog::SetAffirmativeId}{wxdialogsetaffirmativeid} |
| 158 | with the required identifier to be used. Or, override \helpref{wxDialog::DoOK}{wxdialogdook} (return false to |
| 159 | have wxWidgets simply call Close to dismiss the dialog). |
| 160 | |
| 161 | Smartphone dialogs do {\it not} have an OK button on the caption, and are closed |
| 162 | using one of the two menu buttons. You need to assign these using \helpref{wxTopLevelWindow::SetLeftMenu}{wxtoplevelwindowsetleftmenu} |
| 163 | and \helpref{wxTopLevelWindow::SetRightMenu}{wxtoplevelwindowsetrightmenu}, for example: |
| 164 | |
| 165 | \begin{verbatim} |
| 166 | #ifdef __SMARTPHONE__ |
| 167 | SetLeftMenu(wxID_OK); |
| 168 | SetRightMenu(wxID_CANCEL, _("Cancel")); |
| 169 | #elif defined(__POCKETPC__) |
| 170 | // No OK/Cancel buttons on PocketPC, OK on caption will close |
| 171 | #else |
| 172 | topsizer->Add( CreateButtonSizer( wxOK|wxCANCEL ), 0, wxEXPAND | wxALL, 10 ); |
| 173 | #endif |
| 174 | \end{verbatim} |
| 175 | |
| 176 | For implementing property sheets (flat tabs), use a wxNotebook with wxNB\_FLAT|wxNB\_BOTTOM |
| 177 | and have the notebook left, top and right sides overlap the dialog by about 3 pixels |
| 178 | to eliminate spurious borders. You can do this by using a negative spacing in your |
| 179 | sizer Add() call. The cross-platform property sheet dialog \helpref{wxPropertySheetDialog}{wxpropertysheetdialog} is |
| 180 | provided, to show settings in the correct style on PocketPC and on other platforms. |
| 181 | |
| 182 | Notifications (bubble HTML text with optional buttons and links) will also be |
| 183 | implemented in the future for PocketPC. |
| 184 | |
| 185 | Modeless dialogs probably don't make sense for PocketPC and Smartphone, since |
| 186 | frames and dialogs are normally full-screen, and a modeless dialog is normally |
| 187 | intended to co-exist with the main application frame. |
| 188 | |
| 189 | \subsubsection{Menubars and toolbars in wxWinCE} |
| 190 | |
| 191 | \wxheading{Menubars and toolbars in PocketPC} |
| 192 | |
| 193 | On PocketPC, a frame must always have a menubar, even if it's empty. |
| 194 | An empty menubar/toolbar is automatically provided for dialogs, to hide |
| 195 | any existing menubar for the duration of the dialog. |
| 196 | |
| 197 | Menubars and toolbars are implemented using a combined control, |
| 198 | but you can use essentially the usual wxWidgets API; wxWidgets will combine the menubar |
| 199 | and toolbar. However, there are some restrictions: |
| 200 | |
| 201 | \itemsep=0pt |
| 202 | \begin{itemize} |
| 203 | \item You must create the frame's primary toolbar with wxFrame::CreateToolBar, |
| 204 | because this uses the special wxToolMenuBar class (derived from wxToolBar) |
| 205 | to implement the combined toolbar and menubar. Otherwise, you can create and manage toolbars |
| 206 | using the wxToolBar class as usual, for example to implement an optional |
| 207 | formatting toolbar above the menubar as Pocket Word does. But don't assign |
| 208 | a wxToolBar to a frame using SetToolBar - you should always use CreateToolBar |
| 209 | for the main frame toolbar. |
| 210 | \item Deleting and adding tools to wxToolMenuBar after Realize is called is not supported. |
| 211 | \item For speed, colours are not remapped to the system colours as they are |
| 212 | in wxMSW. Provide the tool bitmaps either with the correct system button background, |
| 213 | or with transparency (for example, using XPMs). |
| 214 | \item Adding controls to wxToolMenuBar is not supported. However, wxToolBar supports |
| 215 | controls. |
| 216 | \end{itemize} |
| 217 | |
| 218 | Unlike in all other ports, a wxDialog has a wxToolBar, automatically created |
| 219 | for you. You may either leave it blank, or access it with wxDialog::GetToolBar |
| 220 | and add buttons, then calling wxToolBar::Realize. You cannot set or recreate |
| 221 | the toolbar. |
| 222 | |
| 223 | \wxheading{Menubars and toolbars in Smartphone} |
| 224 | |
| 225 | On Smartphone, there are only two menu buttons, so a menubar is simulated |
| 226 | using a nested menu on the right menu button. Any toolbars are simply ignored on |
| 227 | Smartphone. |
| 228 | |
| 229 | \subsubsection{Closing windows in wxWinCE} |
| 230 | |
| 231 | The guidelines state that applications should not have a Quit menu item, |
| 232 | since the user should not have to know whether an application is in memory |
| 233 | or not. The close button on a window does not call the window's |
| 234 | close handler; it simply hides the window. However, the guidelines say that |
| 235 | the Ctrl+Q accelerator can be used to quit the application, so wxWidgets |
| 236 | defines this accelerator by default and if your application handles |
| 237 | wxID\_EXIT, it will do the right thing. |
| 238 | |
| 239 | \subsubsection{Context menus in wxWinCE} |
| 240 | |
| 241 | To enable context menus in PocketPC, you currently need to call wxWindow::EnableContextMenu, |
| 242 | a wxWinCE-only function. Otherwise the context menu event (wxContextMenuEvent) will |
| 243 | never be sent. This API is subject to change. |
| 244 | |
| 245 | Context menus are not supported in Smartphone. |
| 246 | |
| 247 | \subsubsection{Control differences on wxWinCE} |
| 248 | |
| 249 | These controls and styles are specific to wxWinCE: |
| 250 | |
| 251 | \itemsep=0pt |
| 252 | \begin{itemize} |
| 253 | \item {\bf wxTextCtrl} The wxTE\_CAPITALIZE style causes a CAPEDIT control to |
| 254 | be created, which capitalizes the first letter. |
| 255 | \end{itemize} |
| 256 | |
| 257 | These controls are missing from wxWinCE: |
| 258 | |
| 259 | \itemsep=0pt |
| 260 | \begin{itemize} |
| 261 | \item {\bf MDI classes} MDI is not supported under Windows CE. |
| 262 | \item {\bf wxMiniFrame} Not supported under Windows CE. |
| 263 | \end{itemize} |
| 264 | |
| 265 | Tooltips are not currently supported for controls, since on PocketPC controls with |
| 266 | tooltips are distinct controls, and it will be hard to add dynamic |
| 267 | tooltip support. |
| 268 | |
| 269 | Control borders on PocketPC and Smartphone should normally be specified with |
| 270 | wxSIMPLE\_BORDER instead of wxSUNKEN\_BORDER. Controls will usually adapt |
| 271 | appropriately by virtue of their GetDefaultBorder() function, but if you |
| 272 | wish to specify a style explicitly you can use wxDEFAULT\_CONTROL\_BORDER |
| 273 | which will give a simple border on PocketPC and Smartphone, and the sunken border on |
| 274 | other platforms. |
| 275 | |
| 276 | \subsubsection{Online help in wxWinCE} |
| 277 | |
| 278 | You can use the help controller wxWinceHelpController which controls |
| 279 | simple {\tt .htm} files, usually installed in the Windows directory. |
| 280 | See the Windows CE reference for how to format the HTML files. |
| 281 | |
| 282 | \subsubsection{Installing your PocketPC and Smartphone applications} |
| 283 | |
| 284 | To install your application, you need to build a CAB file using |
| 285 | the parameters defined in a special .inf file. The CabWiz program |
| 286 | in your SDK will compile the CAB file from the .inf file and |
| 287 | files that it specifies. |
| 288 | |
| 289 | For delivery, you can simply ask the user to copy the CAB file to the |
| 290 | device and execute the CAB file using File Explorer. Or, you can |
| 291 | write a program for the desktop PC that will find the ActiveSync |
| 292 | Application Manager and install the CAB file on the device, |
| 293 | which is obviously much easier for the user. |
| 294 | |
| 295 | Here are some links that may help. |
| 296 | |
| 297 | \itemsep=0pt |
| 298 | \begin{itemize} |
| 299 | \item A setup builder that takes CABs and builds a setup program is at \urlref{http://www.eskimo.com/~scottlu/win/index.html}{http://www.eskimo.com/~scottlu/win/index.html}. |
| 300 | \item Sample installation files can be found in {\tt Windows CE Tools/wce420/POCKET PC 2003/Samples/Win32/AppInst}. |
| 301 | \item An installer generator using wxPython can be found at \urlref{http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html}{http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html}. |
| 302 | \item Miscellaneous Windows CE resources can be found at \urlref{http://www.orbworks.com/pcce/resources.html}{http://www.orbworks.com/pcce/resources.html}. |
| 303 | \item Installer creation instructions with a setup.exe for installing to PPC can be found at \urlref{http://www.pocketpcdn.com/articles/creatingsetup.html}{http://www.pocketpcdn.com/articles/creatingsetup.html}. |
| 304 | \item Microsoft instructions are at \urlref{http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true&hidetoc=true}{http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true&hidetoc=true}. |
| 305 | \item Troubleshooting WinCE application installations: \urlref{http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007}{http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007} |
| 306 | \end{itemize} |
| 307 | |
| 308 | You may also check out {\tt demos/life/setup/wince} which contains |
| 309 | scripts to create a PocketPC installation for ARM-based |
| 310 | devices. In particular, {\tt build.bat} builds the distribution and |
| 311 | copies it to a directory called {\tt Deliver}. |
| 312 | |
| 313 | \subsubsection{wxFileDialog in PocketPC} |
| 314 | |
| 315 | Allowing the user to access files on memory cards, or on arbitrary |
| 316 | parts of the filesystem, is a pain; the standard file dialog only |
| 317 | shows folders under My Documents or folders on memory cards |
| 318 | (not the system or card root directory, for example). This is |
| 319 | a known problem for PocketPC developers. |
| 320 | |
| 321 | If you need a file dialog that allows access to all folders, |
| 322 | you can use wxGenericFileDialog instead. You will need to include |
| 323 | {\tt wx/generic/filedlgg.h}. |
| 324 | |
| 325 | \subsubsection{Embedded Visual C++ Issues} |
| 326 | |
| 327 | \wxheading{Run-time type information} |
| 328 | |
| 329 | If you wish to use runtime type information (RTTI) with eVC++ 4, you need to download |
| 330 | an extra library, {\tt ccrtrtti.lib}, and link with it. At the time of |
| 331 | writing you can get it from here: |
| 332 | |
| 333 | \begin{verbatim} |
| 334 | http://support.microsoft.com/kb/830482/en-us |
| 335 | \end{verbatim} |
| 336 | |
| 337 | Otherwise you will get linker errors similar to this: |
| 338 | |
| 339 | \begin{verbatim} |
| 340 | wxwince26d.lib(control.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@) |
| 341 | \end{verbatim} |
| 342 | |
| 343 | \wxheading{Windows Mobile 5.0 emulator} |
| 344 | |
| 345 | Note that there is no separate emulator configuration for Windows Mobile 5.0: the |
| 346 | emulator runs the ARM code directly. |
| 347 | |
| 348 | \wxheading{Visual Studio 2005 project files} |
| 349 | |
| 350 | Unfortunately, Visual Studio 2005, required to build Windows Mobile 5.0 applications, |
| 351 | doesn't do a perfect job of converting the project files from eVC++ format. |
| 352 | |
| 353 | When you have converted the wxWidgets workspace, edit the configuration properties |
| 354 | for each configuration and in the Librarian, add a relative path ..$\backslash$..$\backslash$lib to |
| 355 | each library path. For example: {\tt ..$\backslash$\$(PlatformName)$\backslash$\$(ConfigurationName)$\backslash$wx\_mono.lib}. |
| 356 | |
| 357 | Then, for a sample you want to compile, edit the configuration properties |
| 358 | and make sure {\tt ..$\backslash$..$\backslash$lib$\backslash$\$(PlatformName)$\backslash$\$(ConfigurationName)} is in the Linker/General/Additional |
| 359 | Library Directories property. Also change the Linker/Input/Additional Dependencies |
| 360 | property to something like {\tt coredll.lib wx\_mono.lib wx\_wxjpeg.lib wx\_wxpng.lib wx\_wxzlib.lib wx\_wxexpat.lib commctrl.lib winsock.lib wininet.lib}\rtfsp |
| 361 | (since the library names in the wxWidgets workspace were changed by VS 2005). |
| 362 | |
| 363 | Alternately, you could could edit all the names to be identical to the original eVC++ |
| 364 | names, but this will probably be more fiddly. |
| 365 | |
| 366 | \subsubsection{Remaining issues} |
| 367 | |
| 368 | These are some of the remaining problems to be sorted out, and features |
| 369 | to be supported. |
| 370 | |
| 371 | \itemsep=0pt |
| 372 | \begin{itemize} |
| 373 | \item {\bf Windows Mobile 5 issues.} It is not possible to get the HMENU for |
| 374 | the command bar on Mobile 5, so the menubar functions need to be rewritten |
| 375 | to get the individual menus without use of a menubar handle. Also the |
| 376 | new Mobile 5 convention of using only two menus (and no bitmap buttons) needs to be |
| 377 | considered. |
| 378 | \item {\bf Sizer speed.} Particularly for dialogs containing notebooks, |
| 379 | layout seems slow. Some analysis is required. |
| 380 | \item {\bf Notification boxes.} The balloon-like notification messages, and their |
| 381 | icons, should be implemented. This will be quite straightforward. |
| 382 | \item {\bf SIP size.} We need to be able to get the area taken up by the SIP (input panel), |
| 383 | and the remaining area, by calling SHSipInfo. We also may need to be able to show and hide |
| 384 | the SIP programmatically, with SHSipPreference. See also the {\it Input Dialogs} topic in |
| 385 | the {\it Programming Windows CE} guide for more on this, and how to have dialogs |
| 386 | show the SIP automatically using the WC\_SIPREF control. |
| 387 | \item {\bf wxStaticBitmap.} The About box in the "Life!" demo shows a bitmap that is |
| 388 | the correct size on the emulator, but too small on a VGA Pocket Loox device. |
| 389 | \item {\bf wxStaticLine.} Lines don't show up, and the documentation suggests that |
| 390 | missing styles are implemented with WM\_PAINT. |
| 391 | \item {\bf HTML control.} PocketPC has its own HTML control which can be used for showing |
| 392 | local pages or navigating the web. We should create a version of wxHtmlWindow that uses this |
| 393 | control, or have a separately-named control (wxHtmlCtrl), with a syntax as close as possible to wxHtmlWindow. |
| 394 | \item {\bf Tooltip control.} PocketPC uses special TTBUTTON and TTSTATIC controls for adding |
| 395 | tooltips, with the tooltip separated from the label with a double tilde. We need to support this using SetToolTip. |
| 396 | (Unfortunately it does not seem possible to dynamically remove the tooltip, so an extra style may |
| 397 | be required.) |
| 398 | \item {\bf Focus.} In the wxPropertySheetDialog demo on Smartphone, it's not possible to navigate |
| 399 | between controls. The focus handling in wxWidgets needs investigation. See in particular src/common/containr.cpp, |
| 400 | and note that the default OnActivate handler in src/msw/toplevel.cpp sets the focus to the first child of the dialog. |
| 401 | \item {\bf OK button.} We should allow the OK button on a dialog to be optional, perhaps |
| 402 | by using wxCLOSE\_BOX to indicate when the OK button should be displayed. |
| 403 | \item {\bf Dynamic adaptation.} We should probably be using run-time tests more |
| 404 | than preprocessor tests, so that the same WinCE application can run on different |
| 405 | versions of the operating system. |
| 406 | \item {\bf Modeless dialogs.} When a modeless dialog is hidden with the OK button, it doesn't restore the |
| 407 | frame's menubar. See for example the find dialog in the dialogs sample. However, the menubar is restored |
| 408 | if pressing Cancel (the window is closed). This reflects the fact that modeless dialogs are |
| 409 | not very useful on Windows CE; however, we could perhaps destroy/restore a modeless dialog's menubar |
| 410 | on deactivation and activation. |
| 411 | \item {\bf Home screen plugins.} Figure out how to make home screen plugins for use with wxWidgets |
| 412 | applications (see {\tt http://www.codeproject.com/ce/CTodayWindow.asp} for inspiration). |
| 413 | Although we can't use wxWidgets to create the plugin (too large), we could perhaps write |
| 414 | a generic plugin that takes registry information from a given application, with |
| 415 | options to display information in a particular way using icons and text from |
| 416 | a specified location. |
| 417 | \item {\bf Further abstraction.} We should be able to abstract away more of the differences |
| 418 | between desktop and mobile applications, in particular for sizer layout. |
| 419 | \item {\bf Dialog captions.} The blue, bold captions on dialogs - with optional help button - |
| 420 | should be catered for, either by hard-wiring the capability into all dialogs and panels, |
| 421 | or by providing a standard component and sizer. |
| 422 | \end{itemize} |