1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<title>wxWidgets: Platform Details</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
<link href="extra_stylesheet.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div id="page_container">
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0" style="width: 100%;">
<tbody>
<tr>
<td id="projectlogo">
<a href="http://www.wxwidgets.org/" target="_new">
<img alt="wxWidgets" src="logo.png"/>
</a>
</td>
<td style="padding-left: 0.5em; text-align: right;">
<span id="projectnumber">Version: 3.0.2</span>
</td>
</tr>
</tbody>
</table>
</div>
<!-- Generated by Doxygen 1.8.2 -->
<div id="navrow1" class="tabs">
<ul class="tablist">
<li><a href="index.html"><span>Main Page</span></a></li>
<li class="current"><a href="pages.html"><span>Related Pages</span></a></li>
<li><a href="modules.html"><span>Categories</span></a></li>
<li><a href="annotated.html"><span>Classes</span></a></li>
<li><a href="files.html"><span>Files</span></a></li>
</ul>
</div>
<div id="nav-path" class="navpath">
<ul>
<li class="navelem"><a class="el" href="index.html">Documentation</a></li><li class="navelem"><a class="el" href="page_introduction.html">Introduction</a></li> </ul>
</div>
</div><!-- top -->
<div class="header">
<div class="headertitle">
<div class="title">Platform Details </div> </div>
</div><!--header-->
<div class="contents">
<div class="toc"><h3>Table of Contents</h3>
<ul><li class="level1"><a href="#page_port_wxgtk">wxGTK</a></li>
<li class="level1"><a href="#page_port_wxosx">wxOSX</a><ul><li class="level2"><a href="#page_port_wxosx_carbon">wxOSX/Carbon</a></li>
<li class="level2"><a href="#page_port_wxosx_cocoa">wxOSX/Cocoa</a></li>
</ul>
</li>
<li class="level1"><a href="#page_port_wxos2">wxOS2</a></li>
<li class="level1"><a href="#page_port_wxx11">wxX11</a></li>
<li class="level1"><a href="#page_port_wxmotif">wxMotif</a></li>
<li class="level1"><a href="#page_port_wxmsw">wxMSW</a><ul><li class="level2"><a href="#page_port_wxmsw_themedborders">Themed Borders</a><ul><li class="level3"><a href="#page_port_wxmsw_themedborders_details">Internal Border Implementation</a></li>
</ul>
</li>
<li class="level2"><a href="#page_port_wxmsw_wince">wxWinCE</a><ul><li class="level3"><a href="#page_port_wxmsw_wince_">General Issues for wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_sdk">Testing for WinCE SDKs</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_sizing">Window sizing in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_toplevel">Closing Top-level Windows in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_hibernation">Hibernation in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_hwbutt">Hardware Buttons in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_dialogs">Dialogs in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_ppc">Menubars and Toolbars in PocketPC</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_smart">Menubars and Toolbars in Smartphone</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_closing">Closing Windows in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_ctx">Context Menus in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_ctrl">Control Differences on wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_help">Online Help in wxWinCE</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_install">Installing your PocketPC and Smartphone Applications</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_filedlg">wxFileDialog in PocketPC</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_evc">Embedded Visual C++ Issues</a></li>
<li class="level3"><a href="#page_port_wxmsw_wince_issues">Remaining Issues</a></li>
</ul>
</li>
<li class="level1"><a href="#page_port_nativedocs">Native Toolkit Documentation</a></li>
</ul>
</div>
<div class="textblock"><p>wxWidgets defines a common API across platforms, but uses the native graphical user interface (GUI) on each platform, so your program will take on the native look and feel that users are familiar with.</p>
<p>Unfortunately native toolkits and hardware do not always support the functionality that the wxWidgets API requires. This chapter collects notes about differences among supported platforms and ports.</p>
<h1><a class="anchor" id="page_port_wxgtk"></a>
wxGTK</h1>
<p>wxGTK is a port of wxWidgets using the GTK+ library. It makes use of GTK+'s native widgets wherever possible and uses wxWidgets' generic controls when needed. GTK+ itself has been ported to a number of systems, but so far only the original X11 version is supported. Support for other GTK+ backends is planned, such as the new DirectFB backend.</p>
<p>All work is being done on GTK+ version 2.0 and above. Support for GTK+ 1.2 will be deprecated in a later release.</p>
<p>You will need GTK+ 2.6 or higher which is available from:</p>
<p><a href="http://www.gtk.org">http://www.gtk.org</a></p>
<p>The newer version of GTK+ you use, the more native widgets and features will be utilized. We have gone to great lengths to allow compiling wxWidgets applications with the latest version of GTK+, with the resulting binary working on systems even with a much earlier version of GTK+. You will have to ensure that the application is launched with lazy symbol binding for that.</p>
<p>In order to configure wxWidgets to compile wxGTK you will need use the <code>–with-gtk</code> argument to the <code>configure</code> script. This is the default for many systems.</p>
<p>GTK+ 1.2 can still be used, albeit discouraged. For that you can pass <code>–with-gtk=1</code> to the <code>configure</code> script.</p>
<p>Support for GTK+ 3 is available starting with wxWidgets 2.9.4, use <code>configure</code> option <code>–with-gtk=3</code> to enable it.</p>
<p>For further information, please see the files in <code>docs/gtk</code> in the distribution.</p>
<h1><a class="anchor" id="page_port_wxosx"></a>
wxOSX</h1>
<h2><a class="anchor" id="page_port_wxosx_carbon"></a>
wxOSX/Carbon</h2>
<p>wxOSX/Carbon is a port of wxWidgets for the Macintosh OS platform. Currently OS X 10.5 or higher are supported. wxOSX/Carbon can be compiled both using Apple's command line developer tools as well as Apple's Xcode IDE. wxOSX/Carbon supports both the Intel and PowerPC architectures and can be used to produce "universal binaries" in order create application which can run both architecture. Unfortunately, wxOSX/Carbon does not support any 64-bit architecture since Apple decided not to port its Carbon API entirely to 64-bit.</p>
<dl class="section note"><dt>Note</dt><dd>Carbon has been deprecated by Apple as of OS X 10.5 and will likely be removed entirely in a future OS version. It's recommended you look into switching your app over to wxOSX/Cocoa as soon as possible.</dd></dl>
<p>For further information, please see the files in <code>docs/osx</code> in the distribution.</p>
<h2><a class="anchor" id="page_port_wxosx_cocoa"></a>
wxOSX/Cocoa</h2>
<p>wxOSX/Cocoa is another port of wxWidgets for the Macintosh OS platform. Currently OS X 10.5 or higher are supported. In contrast to wxOSX/Carbon, it uses the Cocoa API in place of Carbon. Much work has gone into this port and many controls are functional, but the port has not reached the maturity of the wxOSX/Carbon port yet. It is possible to use wxOSX/Cocoa on 64-bit architectures.</p>
<p>In order to configure wxWidgets to compile wxOSX/Cocoa you will need to type:</p>
<pre class="fragment">configure --with-osx_cocoa </pre><p>For further information, please see the files in <code>docs/osx</code> in the distribution.</p>
<dl class="section note"><dt>Note</dt><dd>There was a previous effort towards a Cocoa port called wxCocoa, which was implemented totally with Cocoa API unlike the OSX/Cocoa port which uses OS X C APIs to share code, and while it is no longer being actively developed, docs for it are available in <code>docs/cocoa</code> in the distribution.</dd></dl>
<h1><a class="anchor" id="page_port_wxos2"></a>
wxOS2</h1>
<p>wxOS2 is a port of wxWidgets for the IBM OS/2 Warp3 and Warp4 platforms. This port is currently under construction and in beta phase.</p>
<p>For further information, please see the files in <code>docs/os2</code> in the distribution.</p>
<h1><a class="anchor" id="page_port_wxx11"></a>
wxX11</h1>
<p>wxX11 is a port of wxWidgets using X11 (The X Window System) as the underlying graphics backend. wxX11 draws its widgets using the wxUniversal widget set which is now part of wxWidgets. wxX11 is well-suited for a number of special applications such as those running on systems with few resources (PDAs) or for applications which need to use a special themed look.</p>
<p>In order to configure wxWidgets to compile wxX11 you will need to type:</p>
<pre class="fragment">configure --with-x11 --with-universal </pre><p>For further information, please see the files in <code>docs/x11</code> in the distribution. There is also a page on the use of wxWidgets for embedded applications on the wxWidgets web site.</p>
<h1><a class="anchor" id="page_port_wxmotif"></a>
wxMotif</h1>
<p>wxMotif is a port of wxWidgets for X11 systems using Motif libraries. Motif libraries provide a clean and fast user interface at the expense of the beauty and candy of newer interfaces like GTK.</p>
<p>For further information, please see the files in <code>docs/motif</code> in the distribution.</p>
<h1><a class="anchor" id="page_port_wxmsw"></a>
wxMSW</h1>
<p>wxMSW is a port of wxWidgets for the Windows platforms including Windows 95, 98, ME, 2000, NT, XP and Vista in ANSI and Unicode modes (for Windows 9x and ME through the MSLU extension library). wxMSW ensures native look and feel for XP when using wxWidgets version 2.3.3 or higher. wxMSW can be compiled with a great variety of compilers including Microsoft Studio VC++, Borland 5.5, MinGW32, Cygwin and Watcom as well as cross-compilation with a Linux-hosted MinGW32 tool chain.</p>
<p>For further information, please see the files in docs/msw in the distribution.</p>
<h2><a class="anchor" id="page_port_wxmsw_themedborders"></a>
Themed Borders</h2>
<p>Starting with wxWidgets 2.8.5, you can specify the <code>wxBORDER_THEME</code> style to have wxWidgets use a themed border. Using the default XP theme, this is a thin 1-pixel blue border, with an extra 1-pixel border in the window client background colour (usually white) to separate the client area's scrollbars from the border.</p>
<p>If you don't specify a border style for a <a class="el" href="classwx_text_ctrl.html" title="A text control allows text to be displayed and edited.">wxTextCtrl</a> in rich edit mode, wxWidgets now gives the control themed borders automatically, where previously they would take the Windows 95-style sunken border. Other native controls such as <a class="el" href="classwx_text_ctrl.html" title="A text control allows text to be displayed and edited.">wxTextCtrl</a> in non-rich edit mode, and <a class="el" href="classwx_combo_box.html" title="A combobox is like a combination of an edit control and a listbox.">wxComboBox</a> already paint themed borders where appropriate. To use themed borders on other windows, such as <a class="el" href="classwx_panel.html" title="A panel is a window on which controls are placed.">wxPanel</a>, pass the <code>wxBORDER_THEME</code> style, or (apart from <a class="el" href="classwx_panel.html" title="A panel is a window on which controls are placed.">wxPanel</a>) pass no border style.</p>
<p>In general, specifying <code>wxBORDER_THEME</code> will cause a border of some kind to be used, chosen by the platform and control class. To leave the border decision entirely to wxWidgets, pass <code>wxBORDER_DEFAULT</code>. This is not to be confused with specifying <code>wxBORDER_NONE</code>, which says that there should definitely be <em>no</em> border.</p>
<h3><a class="anchor" id="page_port_wxmsw_themedborders_details"></a>
Internal Border Implementation</h3>
<p>The way that wxMSW decides whether to apply a themed border is as follows. The theming code calls <a class="el" href="classwx_window.html#ad95a95e683e57ac6365745b737571582" title="Get the window border style from the given flags: this is different from simply doing flags & wxBORDE...">wxWindow::GetBorder()</a> to obtain a border. If no border style has been passed to the window constructor, GetBorder() calls GetDefaultBorder() for this window. If wxBORDER_THEME was passed to the window constructor, GetBorder() calls GetDefaultBorderForControl().</p>
<p>The implementation of wxWindow::GetDefaultBorder() on wxMSW calls wxWindow::CanApplyThemeBorder() which is a virtual function that tells wxWidgets whether a control can have a theme applied explicitly (some native controls already paint a theme in which case we should not apply it ourselves). Note that <a class="el" href="classwx_panel.html" title="A panel is a window on which controls are placed.">wxPanel</a> is an exception to this rule because in many cases we wish to create a window with no border (for example, notebook pages). So <a class="el" href="classwx_panel.html" title="A panel is a window on which controls are placed.">wxPanel</a> overrides GetDefaultBorder() in order to call the generic wxWindowBase::GetDefaultBorder(), returning wxBORDER_NONE.</p>
<h2><a class="anchor" id="page_port_wxmsw_wince"></a>
wxWinCE</h2>
<p>wxWinCE is the name given to wxMSW when compiled on Windows CE devices; most of wxMSW is common to Win32 and Windows CE but there are some simplifications, enhancements, and differences in behaviour.</p>
<p>For building instructions, see docs/msw/wince in the distribution, also the section about Visual Studio 2005 project files below. The rest of this section documents issues you need to be aware of when programming for Windows CE devices.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_"></a>
General Issues for wxWinCE</h3>
<p>Mobile applications generally have fewer features and simpler user interfaces. Simply omit whole sizers, static lines and controls in your dialogs, and use comboboxes instead of listboxes where appropriate. You also need to reduce the amount of spacing used by sizers, for which you can use a macro such as this:</p>
<div class="fragment"><div class="line"><span class="preprocessor">#if defined(__WXWINCE__)</span></div>
<div class="line"><span class="preprocessor"></span><span class="preprocessor"> #define wxLARGESMALL(large,small) small</span></div>
<div class="line"><span class="preprocessor"></span><span class="preprocessor">#else</span></div>
<div class="line"><span class="preprocessor"></span><span class="preprocessor"> #define wxLARGESMALL(large,small) large</span></div>
<div class="line"><span class="preprocessor"></span><span class="preprocessor">#endif</span></div>
<div class="line"><span class="preprocessor"></span></div>
<div class="line"><span class="comment">// Usage</span></div>
<div class="line">topsizer->Add( CreateTextSizer( message ), 0, <a class="code" href="defs_8h.html#ac0f30319732dcceda470516918ff3556a066863c82a2c08f6f53b663de87c60b6">wxALL</a>, wxLARGESMALL(10,0) );</div>
</div><!-- fragment --><p>There is only ever one instance of a Windows CE application running, and wxWidgets will take care of showing the current instance and shutting down the second instance if necessary.</p>
<p>You can test the return value of <a class="el" href="classwx_system_settings.html#af8a2e5d2411eb520b8dad5fc5e9a1a7a" title="Returns the screen type.">wxSystemSettings::GetScreenType()</a> for a qualitative assessment of what kind of display is available, or use <a class="el" href="group__group__funcmacro__gdi.html#gaefd6b970b2fa62bfc00f386da06ab286" title="Returns the display size in pixels.">wxGetDisplaySize()</a> if you need more information.</p>
<p>You can also use wxGetOsVersion to test for a version of Windows CE at run-time (see the next section). However, because different builds are currently required to target different kinds of device, these values are hard-wired according to the build, and you cannot dynamically adapt the same executable for different major Windows CE platforms. This would require a different approach to the way wxWidgets adapts its behaviour (such as for menubars) to suit the style of device.</p>
<p>See the "Life!" example (demos/life) for an example of an application that has been tailored for PocketPC and Smartphone use.</p>
<dl class="section note"><dt>Note</dt><dd>Don't forget to have this line in your .rc file, as for desktop Windows applications:</dd></dl>
<pre class="fragment">#include "wx/msw/wx.rc" </pre><h3><a class="anchor" id="page_port_wxmsw_wince_sdk"></a>
Testing for WinCE SDKs</h3>
<p>Use these preprocessor symbols to test for the different types of devices:</p>
<ul>
<li><b><b>SMARTPHONE</b></b> Generic mobile devices with phone buttons and a small display </li>
<li><b><b>PDA</b></b> Generic mobile devices with no phone </li>
<li><b><b>HANDHELDPC</b></b> Generic mobile device with a keyboard </li>
<li><b><b>WXWINCE</b></b> Microsoft-powered Windows CE devices, whether PocketPC, Smartphone or Standard SDK </li>
<li><b>WIN32_PLATFORM_WFSP</b> Microsoft-powered smartphone </li>
<li><b><b>POCKETPC</b></b> Microsoft-powered PocketPC devices with touch-screen </li>
<li><b><b>WINCE_STANDARDSDK</b></b> Microsoft-powered Windows CE devices, for generic Windows CE applications </li>
<li><b><b>WINCE_NET</b></b> Microsoft-powered Windows CE .NET devices (_WIN32_WCE is 400 or greater)</li>
</ul>
<p><a class="el" href="group__group__funcmacro__networkuseros.html#ga2ca585c288b956d80511478dc7b01533" title="Gets the version and the operating system ID for currently running OS.">wxGetOsVersion()</a> will return these values:</p>
<ul>
<li><b>wxWINDOWS_POCKETPC</b> The application is running under PocketPC. </li>
<li><b>wxWINDOWS_SMARTPHONE</b> The application is running under Smartphone. </li>
<li><b>wxWINDOWS_CE</b> The application is running under Windows CE (built with the Standard SDK).</li>
</ul>
<h3><a class="anchor" id="page_port_wxmsw_wince_sizing"></a>
Window sizing in wxWinCE</h3>
<p>Top level windows (dialogs, frames) are created always full-screen. Fit() of sizers will not rescale top level windows but instead will scale window content.</p>
<p>If the screen orientation changes, the windows will automatically be resized so no further action needs to be taken (unless you want to change the layout according to the orientation, which you could detect in idle time, for example). When input panel (SIP) is shown, top level windows (frames and dialogs) resize accordingly (see <a class="el" href="classwx_top_level_window.html#ac804159a17302c7e805d70ff4911318c" title="Unique to the wxWinCE port.">wxTopLevelWindow::HandleSettingChange()</a>).</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_toplevel"></a>
Closing Top-level Windows in wxWinCE</h3>
<p>You won't get a <a class="el" href="classwx_close_event.html" title="This event class contains information about window and session close events.">wxCloseEvent</a> when the user clicks on the X in the titlebar on Smartphone and PocketPC; the window is simply hidden instead. However the system may send the event to force the application to close down.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_hibernation"></a>
Hibernation in wxWinCE</h3>
<p>Smartphone and PocketPC will send a <code>wxEVT_HIBERNATE</code> to the application object in low memory conditions. Your application should release memory and close dialogs, and wake up again when the next <code>wxEVT_ACTIVATE</code> or <code>wxEVT_ACTIVATE_APP</code> message is received. (<code>wxEVT_ACTIVATE_APP</code> is generated whenever a <code>wxEVT_ACTIVATE</code> event is received in Smartphone and PocketPC, since these platforms do not support <code>WM_ACTIVATEAPP</code>.)</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_hwbutt"></a>
Hardware Buttons in wxWinCE</h3>
<p>Special hardware buttons are sent to a window via the <code>wxEVT_HOTKEY</code> event under Smartphone and PocketPC. You should first register each required button with <a class="el" href="classwx_window.html#a53ca57872dac5851ea6ba55a494b899b" title="Registers a system wide hotkey.">wxWindow::RegisterHotKey()</a>, and unregister the button when you're done with it. For example:</p>
<div class="fragment"><div class="line">win->RegisterHotKey(0, <a class="code" href="defs_8h.html#a5b81968ab866f5874cabc504490ae5cda5a287f69b590d3fd245970caaa61a8da">wxMOD_WIN</a>, <a class="code" href="defs_8h.html#a41c4609211685cff198618963ec8f77dabde23340ad1723b2b641cc10fd319bb0" title="Hardware-specific buttons.">WXK_SPECIAL1</a>);</div>
<div class="line">win->UnregisterHotKey(0);</div>
</div><!-- fragment --><p>You may have to register the buttons in a <code>wxEVT_ACTIVATE</code> event handler since other applications will grab the buttons.</p>
<p>There is currently no method of finding out the names of the special buttons or how many there are.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_dialogs"></a>
Dialogs in wxWinCE</h3>
<p>PocketPC dialogs have an OK button on the caption, and so you should generally not repeat an OK button on the dialog. You can add a Cancel button if necessary, but some dialogs simply don't offer you the choice (the guidelines recommend you offer an Undo facility to make up for it). When the user clicks on the OK button, your dialog will receive a <code>wxID_OK</code> event by default. If you wish to change this, call <a class="el" href="classwx_dialog.html#a72ea7e269bedb2552bfeaccdbac07939" title="Sets the identifier to be used as OK button.">wxDialog::SetAffirmativeId()</a> with the required identifier to be used. Or, override <a class="el" href="classwx_dialog.html#a08a07820be45f6c6fcde5c9e2f786389" title="This function is called when the titlebar OK button is pressed (PocketPC only).">wxDialog::DoOK()</a> (return <span class="literal">false</span> to have wxWidgets simply call Close to dismiss the dialog).</p>
<p>Smartphone dialogs do <em>not</em> have an OK button on the caption, and are closed using one of the two menu buttons. You need to assign these using <a class="el" href="classwx_top_level_window.html#a198cff4212ff5342c0c4358b59274fd5" title="Sets action or menu activated by pressing left hardware button on the smart phones.">wxTopLevelWindow::SetLeftMenu</a> and <a class="el" href="classwx_top_level_window.html#a98e95b1b10f44b80f9b29a03ab09a879" title="Sets action or menu activated by pressing right hardware button on the smart phones.">wxTopLevelWindow::SetRightMenu()</a>, for example:</p>
<div class="fragment"><div class="line"><span class="preprocessor">#ifdef __SMARTPHONE__</span></div>
<div class="line"><span class="preprocessor"></span> SetLeftMenu(<a class="code" href="defs_8h.html#ac66d0a09761e7d86b2ac0b2e0c6a8cbbaeeb1bdf97306d7f0fdffb62c8af3d02f" title="Standard button and menu IDs.">wxID_OK</a>);</div>
<div class="line"> SetRightMenu(<a class="code" href="defs_8h.html#ac66d0a09761e7d86b2ac0b2e0c6a8cbba27aec3f2d4b5cf0e36c028bbab048206">wxID_CANCEL</a>, <a class="code" href="group__group__funcmacro__string.html#ga8a02b8875a521df57263a9e6f090f2d0" title="Macro to be used around all literal strings that should be translated.">_</a>(<span class="stringliteral">"Cancel"</span>));</div>
<div class="line"><span class="preprocessor">#elif defined(__POCKETPC__)</span></div>
<div class="line"><span class="preprocessor"></span> <span class="comment">// No OK/Cancel buttons on PocketPC, OK on caption will close</span></div>
<div class="line"><span class="preprocessor">#else</span></div>
<div class="line"><span class="preprocessor"></span> topsizer->Add( CreateButtonSizer( <a class="code" href="defs_8h.html#a9c40266b61a27f0124a69a699753889a">wxOK</a>|<a class="code" href="defs_8h.html#a5580412e224117ac127aacaafd49dc2e">wxCANCEL</a> ), 0, <a class="code" href="defs_8h.html#a27b6b668631a5f79f24d474af7d9b388a0d831bd6985c81f9bbc4830cc0c2e7df">wxEXPAND</a> | <a class="code" href="defs_8h.html#ac0f30319732dcceda470516918ff3556a066863c82a2c08f6f53b663de87c60b6">wxALL</a>, 10 );</div>
<div class="line"><span class="preprocessor">#endif</span></div>
</div><!-- fragment --><p>For implementing property sheets (flat tabs), use a <a class="el" href="classwx_notebook.html" title="This class represents a notebook control, which manages multiple windows with associated tabs...">wxNotebook</a> with <code>wxNB_FLAT|wxNB_BOTTOM</code> and have the notebook left, top and right sides overlap the dialog by about 3 pixels to eliminate spurious borders. You can do this by using a negative spacing in your sizer Add() call. The cross-platform property sheet dialog <a class="el" href="classwx_property_sheet_dialog.html" title="This class represents a property sheet dialog: a tabbed dialog for showing settings.">wxPropertySheetDialog</a> is provided, to show settings in the correct style on PocketPC and on other platforms.</p>
<p>Notifications (bubble HTML text with optional buttons and links) will also be implemented in the future for PocketPC.</p>
<p>Modeless dialogs probably don't make sense for PocketPC and Smartphone, since frames and dialogs are normally full-screen, and a modeless dialog is normally intended to co-exist with the main application frame.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_ppc"></a>
Menubars and Toolbars in PocketPC</h3>
<p>On PocketPC, a frame must always have a menubar, even if it's empty. An empty menubar/toolbar is automatically provided for dialogs, to hide any existing menubar for the duration of the dialog.</p>
<p>Menubars and toolbars are implemented using a combined control, but you can use essentially the usual wxWidgets API; wxWidgets will combine the menubar and toolbar. However, there are some restrictions:</p>
<ul>
<li>You must create the frame's primary toolbar with <a class="el" href="classwx_frame.html#a17b7fb1c9859d5612a45a79f55cb3d27" title="Creates a toolbar at the top or left of the frame.">wxFrame::CreateToolBar()</a>, because this uses the special wxToolMenuBar class (derived from <a class="el" href="classwx_tool_bar.html" title="A toolbar is a bar of buttons and/or other controls usually placed below the menu bar in a wxFrame...">wxToolBar</a>) to implement the combined toolbar and menubar. Otherwise, you can create and manage toolbars using the <a class="el" href="classwx_tool_bar.html" title="A toolbar is a bar of buttons and/or other controls usually placed below the menu bar in a wxFrame...">wxToolBar</a> class as usual, for example to implement an optional formatting toolbar above the menubar as Pocket Word does. But don't assign a <a class="el" href="classwx_tool_bar.html" title="A toolbar is a bar of buttons and/or other controls usually placed below the menu bar in a wxFrame...">wxToolBar</a> to a frame using SetToolBar - you should always use CreateToolBar for the main frame toolbar. </li>
<li>Deleting and adding tools to wxToolMenuBar after Realize is called is not supported. </li>
<li>For speed, colours are not remapped to the system colours as they are in wxMSW. Provide the tool bitmaps either with the correct system button background, or with transparency (for example, using XPMs). </li>
<li>Adding controls to wxToolMenuBar is not supported. However, <a class="el" href="classwx_tool_bar.html" title="A toolbar is a bar of buttons and/or other controls usually placed below the menu bar in a wxFrame...">wxToolBar</a> supports controls.</li>
</ul>
<p>Unlike in all other ports, a <a class="el" href="classwx_dialog.html" title="A dialog box is a window with a title bar and sometimes a system menu, which can be moved around the ...">wxDialog</a> has a <a class="el" href="classwx_tool_bar.html" title="A toolbar is a bar of buttons and/or other controls usually placed below the menu bar in a wxFrame...">wxToolBar</a> automatically created for you. You may either leave it blank, or access it with <a class="el" href="classwx_dialog.html#a80c76ed6b8f6eb92992f816e1a987f80" title="On PocketPC, a dialog is automatically provided with an empty toolbar.">wxDialog::GetToolBar()</a> and add buttons, then calling <a class="el" href="classwx_tool_bar.html#abb31ce337a2d3c1e30e8e3748905ecbf" title="This function should be called after you have added tools.">wxToolBar::Realize()</a>. You cannot set or recreate the toolbar.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_smart"></a>
Menubars and Toolbars in Smartphone</h3>
<p>On Smartphone, there are only two menu buttons, so a menubar is simulated using a nested menu on the right menu button. Any toolbars are simply ignored on Smartphone.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_closing"></a>
Closing Windows in wxWinCE</h3>
<p>The guidelines state that applications should not have a Quit menu item, since the user should not have to know whether an application is in memory or not. The close button on a window does not call the window's close handler; it simply hides the window. However, the guidelines say that the Ctrl+Q accelerator can be used to quit the application, so wxWidgets defines this accelerator by default and if your application handles wxID_EXIT, it will do the right thing.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_ctx"></a>
Context Menus in wxWinCE</h3>
<p>To enable context menus in PocketPC, you currently need to call wxWindow::EnableContextMenu(), a wxWinCE-only function. Otherwise the context menu event (<a class="el" href="classwx_context_menu_event.html" title="This class is used for context menu events, sent to give the application a chance to show a context (...">wxContextMenuEvent</a>) will never be sent. This API is subject to change.</p>
<p>Context menus are not supported in Smartphone.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_ctrl"></a>
Control Differences on wxWinCE</h3>
<p>These controls and styles are specific to wxWinCE:</p>
<ul>
<li><a class="el" href="classwx_text_ctrl.html" title="A text control allows text to be displayed and edited.">wxTextCtrl</a> The <code>wxTE_CAPITALIZE</code> style causes a CAPEDIT control to be created, which capitalizes the first letter.</li>
</ul>
<p>These controls are missing from wxWinCE:</p>
<ul>
<li>MDI classes MDI is not supported under Windows CE. </li>
<li><a class="el" href="classwx_mini_frame.html" title="A miniframe is a frame with a small title bar.">wxMiniFrame</a> Not supported under Windows CE.</li>
</ul>
<p>Tooltips are not currently supported for controls, since on PocketPC controls with tooltips are distinct controls, and it will be hard to add dynamic tooltip support.</p>
<p>Control borders on PocketPC and Smartphone should normally be specified with <code>wxBORDER_SIMPLE</code> instead of <code>wxBORDER_SUNKEN</code>. Controls will usually adapt appropriately by virtue of their GetDefaultBorder() function, but if you wish to specify a style explicitly you can use <code>wxDEFAULT_CONTROL_BORDER</code> which will give a simple border on PocketPC and Smartphone, and the sunken border on other platforms.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_help"></a>
Online Help in wxWinCE</h3>
<p>You can use the help controller wxWinceHelpController which controls simple <code></code>.htm files, usually installed in the Windows directory. See the Windows CE reference for how to format the HTML files.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_install"></a>
Installing your PocketPC and Smartphone Applications</h3>
<p>To install your application, you need to build a CAB file using the parameters defined in a special .inf file. The CabWiz program in your SDK will compile the CAB file from the .inf file and files that it specifies.</p>
<p>For delivery, you can simply ask the user to copy the CAB file to the device and execute the CAB file using File Explorer. Or, you can write a program for the desktop PC that will find the ActiveSync Application Manager and install the CAB file on the device, which is obviously much easier for the user.</p>
<p>Here are some links that may help.</p>
<ul>
<li>A setup builder that takes CABs and builds a setup program is at <a href="http://www.eskimo.com/~scottlu/win/index.html">http://www.eskimo.com/~scottlu/win/index.html</a>. </li>
<li>Sample installation files can be found in <code>Windows CE Tools/wce420/POCKET PC 2003/Samples/Win32/AppInst</code>. </li>
<li>An installer generator using wxPython can be found at <a href="http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html">http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html</a>. </li>
<li>Miscellaneous Windows CE resources can be found at <a href="http://www.orbworks.com/pcce/resources.html">http://www.orbworks.com/pcce/resources.html</a>. </li>
<li>Installer creation instructions with a setup.exe for installing to PPC can be found at <a href="http://www.pocketpcdn.com/articles/creatingsetup.html">http://www.pocketpcdn.com/articles/creatingsetup.html</a>. </li>
<li>Microsoft instructions are at <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true</a> </li>
<li>Troubleshooting WinCE application installations: <a href="http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007">http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007</a></li>
</ul>
<p>You may also check out <code>demos/life/setup/wince</code> which contains scripts to create a PocketPC installation for ARM-based devices. In particular, <code>build.bat</code> builds the distribution and copies it to a directory called <code>Deliver</code>.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_filedlg"></a>
wxFileDialog in PocketPC</h3>
<p>Allowing the user to access files on memory cards, or on arbitrary parts of the filesystem, is a pain; the standard file dialog only shows folders under My Documents or folders on memory cards (not the system or card root directory, for example). This is a known problem for PocketPC developers.</p>
<p>If you need a file dialog that allows access to all folders, you can use wxGenericFileDialog instead. You will need to include <code>wx/generic/filedlgg.h</code>.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_evc"></a>
Embedded Visual C++ Issues</h3>
<p><b>Run-time type information</b></p>
<p>If you wish to use runtime type information (RTTI) with eVC++ 4, you need to download an extra library, <code>ccrtrtti.lib</code>, and link with it. At the time of writing you can get it from here:</p>
<pre class="fragment">http://support.microsoft.com/kb/830482/en-us
</pre><p>Otherwise you will get linker errors similar to this:</p>
<pre class="fragment">wxwince26d.lib(control.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
</pre><p><b>Windows Mobile 5.0 emulator</b></p>
<p>Note that there is no separate emulator configuration for Windows Mobile 5.0: the emulator runs the ARM code directly.</p>
<p><b>Visual Studio 2005 project files</b></p>
<p>Unfortunately, Visual Studio 2005, required to build Windows Mobile 5.0 applications, doesn't do a perfect job of converting the project files from eVC++ format.</p>
<p>When you have converted the wxWidgets workspace, edit the configuration properties for each configuration and in the Librarian, add a relative path</p>
<pre class="fragment">..\..\lib </pre><p>to each library path. For example:</p>
<pre class="fragment">..\$(PlatformName)\$(ConfigurationName)\wx_mono.lib </pre><p>Then, for a sample you want to compile, edit the configuration properties and make sure</p>
<pre class="fragment">..\..\lib\$(PlatformName)\$(ConfigurationName) </pre><p>is in the Linker/General/Additional Library Directories property. Also change the Linker/Input/Additional Dependencies property to something like</p>
<pre class="fragment">coredll.lib wx_mono.lib wx_wxjpeg.lib wx_wxpng.lib wx_wxzlib.lib wx_wxexpat.lib commctrl.lib winsock.lib wininet.lib
</pre><p>since the library names in the wxWidgets workspace were changed by VS 2005.</p>
<p>Alternately, you could edit all the names to be identical to the original eVC++ names, but this will probably be more fiddly.</p>
<h3><a class="anchor" id="page_port_wxmsw_wince_issues"></a>
Remaining Issues</h3>
<p>These are some of the remaining problems to be sorted out, and features to be supported.</p>
<ul>
<li><b>Windows Mobile 5 issues.</b> It is not possible to get the HMENU for the command bar on Mobile 5, so the menubar functions need to be rewritten to get the individual menus without use of a menubar handle. Also the new Mobile 5 convention of using only two menus (and no bitmap buttons) needs to be considered. </li>
<li><b>Sizer speed.</b> Particularly for dialogs containing notebooks, layout seems slow. Some analysis is required. </li>
<li><b>Notification boxes.</b> The balloon-like notification messages, and their icons, should be implemented. This will be quite straightforward. </li>
<li><b>SIP size.</b> We need to be able to get the area taken up by the SIP (input panel), and the remaining area, by calling SHSipInfo. We also may need to be able to show and hide the SIP programmatically, with SHSipPreference. See also the <em>Input Dialogs</em> topic in the <em>Programming Windows CE</em> guide for more on this, and how to have dialogs show the SIP automatically using the <code>WC_SIPREF</code> control. </li>
<li><b><a class="el" href="classwx_static_bitmap.html" title="A static bitmap control displays a bitmap.">wxStaticBitmap</a>.</b> The About box in the "Life!" demo shows a bitmap that is the correct size on the emulator, but too small on a VGA Pocket Loox device. </li>
<li><b><a class="el" href="classwx_static_line.html" title="A static line is just a line which may be used in a dialog to separate the groups of controls...">wxStaticLine</a>.</b> Lines don't show up, and the documentation suggests that missing styles are implemented with <code>WM_PAINT</code>. </li>
<li><b>HTML control.</b> PocketPC has its own HTML control which can be used for showing local pages or navigating the web. We should create a version of <a class="el" href="classwx_html_window.html" title="wxHtmlWindow is probably the only class you will directly use unless you want to do something special...">wxHtmlWindow</a> that uses this control, or have a separately-named control (wxHtmlCtrl), with a syntax as close as possible to <a class="el" href="classwx_html_window.html" title="wxHtmlWindow is probably the only class you will directly use unless you want to do something special...">wxHtmlWindow</a>. </li>
<li><b>Tooltip control.</b> PocketPC uses special TTBUTTON and TTSTATIC controls for adding tooltips, with the tooltip separated from the label with a double tilde. We need to support this using SetToolTip.(Unfortunately it does not seem possible to dynamically remove the tooltip, so an extra style may be required.) </li>
<li><b>Focus.</b> In the <a class="el" href="classwx_property_sheet_dialog.html" title="This class represents a property sheet dialog: a tabbed dialog for showing settings.">wxPropertySheetDialog</a> demo on Smartphone, it's not possible to navigate between controls. The focus handling in wxWidgets needs investigation. See in particular src/common/containr.cpp, and note that the default OnActivate handler in src/msw/toplevel.cpp sets the focus to the first child of the dialog. </li>
<li><b>OK button.</b> We should allow the OK button on a dialog to be optional, perhaps by using <code>wxCLOSE_BOX</code> to indicate when the OK button should be displayed. </li>
<li><b>Dynamic adaptation.</b> We should probably be using run-time tests more than preprocessor tests, so that the same WinCE application can run on different versions of the operating system. </li>
<li><b>Modeless dialogs.</b> When a modeless dialog is hidden with the OK button, it doesn't restore the frame's menubar. See for example the find dialog in the dialogs sample. However, the menubar is restored if pressing Cancel (the window is closed). This reflects the fact that modeless dialogs are not very useful on Windows CE; however, we could perhaps destroy/restore a modeless dialog's menubar on deactivation and activation. </li>
<li><b>Home screen plugins.</b> Figure out how to make home screen plugins for use with wxWidgets applications (see <a href="http://www.codeproject.com/ce/CTodayWindow.asp">http://www.codeproject.com/ce/CTodayWindow.asp</a> for inspiration). Although we can't use wxWidgets to create the plugin (too large), we could perhaps write a generic plugin that takes registry information from a given application, with options to display information in a particular way using icons and text from a specified location. </li>
<li><b>Further abstraction.</b> We should be able to abstract away more of the differences between desktop and mobile applications, in particular for sizer layout. </li>
<li><b>Dialog captions.</b> The blue, bold captions on dialogs - with optional help button - should be catered for, either by hard-wiring the capability into all dialogs and panels, or by providing a standard component and sizer.</li>
</ul>
<h1><a class="anchor" id="page_port_nativedocs"></a>
Native Toolkit Documentation</h1>
<p>It's sometimes useful to interface directly with the underlying toolkit used by wxWidgets to e.g. use toolkit-specific features. In such case (or when you want to e.g. write a port-specific patch) it can be necessary to use the underlying toolkit API directly:</p>
<ul>
<li>wxMSW port uses win32 API: see MSDN docs at <a href="http://msdn2.microsoft.com/en-us/library/ms649779.aspx">http://msdn2.microsoft.com/en-us/library/ms649779.aspx</a></li>
<li>wxGTK port uses GTK+ and other lower-level libraries; see<ul>
<li>GTK+ docs at <a href="http://library.gnome.org/devel/gtk/unstable/">http://library.gnome.org/devel/gtk/unstable/</a></li>
<li>GDK docs at <a href="http://library.gnome.org/devel/gdk/unstable/">http://library.gnome.org/devel/gdk/unstable/</a></li>
<li>GLib docs at <a href="http://library.gnome.org/devel/glib/unstable/">http://library.gnome.org/devel/glib/unstable/</a></li>
<li>GObject docs at <a href="http://library.gnome.org/devel/gobject/unstable/">http://library.gnome.org/devel/gobject/unstable/</a></li>
<li>Pango docs at <a href="http://library.gnome.org/devel/pango/unstable/">http://library.gnome.org/devel/pango/unstable/</a></li>
</ul>
</li>
<li>wxMac port uses the Carbon API: see Carbon docs at <a href="http://developer.apple.com/carbon">http://developer.apple.com/carbon</a></li>
<li>wxCocoa port uses the Cocoa API: see Cocoa docs at <a href="http://developer.apple.com/cocoa">http://developer.apple.com/cocoa</a> </li>
</ul>
</div></div><!-- contents -->
<address class="footer">
<small>
Generated on Thu Nov 27 2014 13:46:42 for wxWidgets by <a href="http://www.doxygen.org/index.html" target="_new">Doxygen</a> 1.8.2
</small>
</address>
<script src="wxwidgets.js" type="text/javascript"></script>
</div><!-- #page_container -->
</body>
</html>
|
