removed almost all TeX code from main manual pages
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@51913 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Francesco Montorsi
@@ -18,18 +18,566 @@
|
||||
requires. This chapter collects notes about differences among supported platforms
|
||||
and ports.
|
||||
|
||||
@li @ref wxgtkport
|
||||
@li @ref wxmacport
|
||||
@li @ref wxos2port
|
||||
@li @ref wxmglport
|
||||
@li @ref wxx11port
|
||||
@li @ref wxmswport
|
||||
@li @ref nativedocs
|
||||
|
||||
|
||||
<hr>
|
||||
|
||||
\input wxgtk.tex
|
||||
\input wxmsw.tex
|
||||
\input wxmac.tex
|
||||
\input wxpalm.tex
|
||||
\input wxos2.tex
|
||||
\input wxmgl.tex
|
||||
\input wxx11.tex
|
||||
|
||||
|
||||
@section wxgtkport wxGTK port
|
||||
|
||||
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.
|
||||
|
||||
All work is being done on GTK+ version 2.0 and above. Support for
|
||||
GTK+ 1.2 will be deprecated in a later release.
|
||||
|
||||
You will need GTK+ 2.0 or higher which is available from:
|
||||
|
||||
http://www.gtk.org
|
||||
|
||||
The newer version of GTK+ you use, the more native widgets and
|
||||
features will be utilized. We have gone to a great extent to
|
||||
allow compiling wxWidgets applications with a latest version of
|
||||
GTK+, with the resulting binary working on systems even with a
|
||||
much lower version of GTK+. You will have to ensure that the
|
||||
application is launched with lazy symbol binding for that.
|
||||
|
||||
In order to configure wxWidgets to compile wxGTK you will
|
||||
need use the @c --with-gtk argument to the @c configure script.
|
||||
This is the default for many systems.
|
||||
|
||||
GTK+ 1.2 can still be used, albeit discouraged. For that you can
|
||||
pass @c --with-gtk=1 to the @c configure script.
|
||||
|
||||
For further information, please see the files in docs/gtk
|
||||
in the distribution.
|
||||
|
||||
|
||||
|
||||
|
||||
@section wxmacport wxMac port
|
||||
|
||||
wxMac is a port of wxWidgets for the Macintosh OS platform.
|
||||
Currently MacOS 8.6 or higher, MacOS 9.0 or higher and
|
||||
MacOS X 10.0 or higher are supported, although most development
|
||||
effort goes into MacOS X support. wxMac can be compiled both
|
||||
using Apple's developer tools and MetroWerks CodeWarrior in
|
||||
different versions. Support for MacOS 8.X and MacOS 9.X is
|
||||
only available through CodeWarrior. wxMac uses the Carbon
|
||||
API (and optionally the Classic API under MacOS 8.X). You
|
||||
will need wxWidgets version 2.3.3 or higher for a stable
|
||||
version of wxMac.
|
||||
|
||||
For further information, please see the files in docs/mac
|
||||
in the distribution.
|
||||
|
||||
|
||||
|
||||
|
||||
@section wxmglport wxMGL port
|
||||
|
||||
wxMGL is a port of wxWidgets using the MGL library available
|
||||
from SciTech as the underlying graphics backend. wxMGL draws
|
||||
its widgets using the wxUniversal widget set which is now
|
||||
part of wxWidgets. MGL itself runs on a variety of platforms
|
||||
including DOS, Linux hardware (similar to the Linux framebuffer)
|
||||
and various graphics systems such as Win32, X11 and OS/2.
|
||||
Note that currently MGL for Linux runs only on x86-based systems.
|
||||
|
||||
You will need wxWidgets 2.3.3 or higher and MGL 5.0 or higher.
|
||||
The latter is available from
|
||||
|
||||
http://www.scitechsoft.com/products/product_download.html
|
||||
|
||||
In order to configure wxWidgets to compile wxMGL you will
|
||||
need to type:
|
||||
|
||||
@verbatim configure --with-mgl --with-universal @endverbatim
|
||||
|
||||
Under DOS, wxMGL uses a dmake based make system.
|
||||
|
||||
For further information, please see the files in docs/mgl
|
||||
in the distribution.
|
||||
|
||||
|
||||
|
||||
@section wxos2port wxOS2 port
|
||||
|
||||
wxOS2 is a port of wxWidgets for the IBM OS/2 platform.
|
||||
It is currently under construction.
|
||||
|
||||
|
||||
|
||||
@section wxx11port wxX11 port
|
||||
|
||||
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. You will need
|
||||
wxWidgets 2.3.2 or higher.
|
||||
|
||||
In order to configure wxWidgets to compile wxX11 you will
|
||||
need to type:
|
||||
|
||||
@verbatim configure --with-x11 --with-universal @endverbatim
|
||||
|
||||
For further information, please see the files in docs/x11
|
||||
in the distribution. There is also a page on the use of
|
||||
wxWidgets for embedded applications on the wxWidgets web site.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@section wxmswport wxMSW port
|
||||
|
||||
wxMSW is a port of wxWidgets for the Windows platforms
|
||||
including Windows 95, 98, ME, 2000, NT, XP in ANSI and
|
||||
Unicode mode (for Windows 95 through the MSLU extension
|
||||
library). wxMSW ensures native look and feel for XP
|
||||
as well when using wxWidgets version 2.3.3 or higher.
|
||||
wxMSW can be compile with a great variety of compilers
|
||||
including MS VC++, Borland 5.5, MinGW32, Cygwin and
|
||||
Watcom as well as cross-compilation with a Linux hosted
|
||||
MinGW32 tool chain.
|
||||
|
||||
For further information, please see the files in docs/msw
|
||||
in the distribution.
|
||||
|
||||
@subsection wxmswthemedborders Themed borders on Windows
|
||||
|
||||
Starting with wxWidgets 2.8.5, you can specify the wxBORDER_THEME 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.
|
||||
|
||||
If you don't specify a border style for a wxTextCtrl 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 wxTextCtrl in non-rich edit mode, and wxComboBox,
|
||||
already paint themed borders where appropriate. To use themed borders on other windows, such
|
||||
as wxPanel, pass the wxBORDER_THEME style, or (apart from wxPanel) pass no border style.
|
||||
|
||||
In general, specifying wxBORDER_THEME 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 wxBORDER_DEFAULT.
|
||||
This is not to be confused with specifying wxBORDER_NONE, which says that there should
|
||||
definitely be @e no border.
|
||||
|
||||
@subsubsection wxmswthemedborders_details More detail on border implementation
|
||||
|
||||
The way that wxMSW decides whether to apply a themed border is as follows.
|
||||
The theming code calls wxWindow::GetBorder() 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().
|
||||
|
||||
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 wxPanel is an exception to this rule because in many cases
|
||||
we wish to create a window with no border (for example, notebook pages). So wxPanel
|
||||
overrides GetDefaultBorder() in order to call the generic wxWindowBase::GetDefaultBorder(),
|
||||
returning wxBORDER_NONE.
|
||||
|
||||
@subsection wxwince wxWinCE
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
@subsubsection port_ General issues for wxWinCE programming
|
||||
|
||||
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:
|
||||
|
||||
@verbatim
|
||||
#if defined(__WXWINCE__)
|
||||
#define wxLARGESMALL(large,small) small
|
||||
#else
|
||||
#define wxLARGESMALL(large,small) large
|
||||
#endif
|
||||
|
||||
// Usage
|
||||
topsizer->Add( CreateTextSizer( message ), 0, wxALL, wxLARGESMALL(10,0) );
|
||||
@endverbatim
|
||||
|
||||
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.
|
||||
|
||||
You can test the return value of wxSystemSettings::GetScreenType()
|
||||
for a qualitative assessment of what kind of display is available,
|
||||
or use wxGetDisplaySize() if you need more information.
|
||||
|
||||
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.
|
||||
|
||||
See the "Life!" example (demos/life) for an example of
|
||||
an application that has been tailored for PocketPC and Smartphone use.
|
||||
|
||||
@note don't forget to have this line in your .rc file, as for
|
||||
desktop Windows applications:
|
||||
|
||||
@verbatim #include "wx/msw/wx.rc" @endverbatim
|
||||
|
||||
@subsubsection port_ Testing for WinCE SDKs
|
||||
|
||||
Use these preprocessor symbols to test for the different types of device or SDK:
|
||||
|
||||
@li @b __SMARTPHONE__ Generic mobile devices with phone buttons and a small display
|
||||
@li @b __PDA__ Generic mobile devices with no phone
|
||||
@li @b __HANDHELDPC__ Generic mobile device with a keyboard
|
||||
@li @b __WXWINCE__ Microsoft-powered Windows CE devices, whether PocketPC, Smartphone or Standard SDK
|
||||
@li @b WIN32_PLATFORM_WFSP Microsoft-powered smartphone
|
||||
@li @b __POCKETPC__ Microsoft-powered PocketPC devices with touch-screen
|
||||
@li @b __WINCE_STANDARDSDK__ Microsoft-powered Windows CE devices, for generic Windows CE applications
|
||||
@li @b __WINCE_NET__ Microsoft-powered Windows CE .NET devices (_WIN32_WCE is 400 or greater)
|
||||
|
||||
wxGetOsVersion will return these values:
|
||||
|
||||
@li @b wxWINDOWS_POCKETPC The application is running under PocketPC.
|
||||
@li @b wxWINDOWS_SMARTPHONE The application is running under Smartphone.
|
||||
@li @b wxWINDOWS_CE The application is running under Windows CE (built with the Standard SDK).
|
||||
|
||||
|
||||
@subsubsection port_ Window sizing in wxWinCE
|
||||
|
||||
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.
|
||||
|
||||
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 wxTopLevelWindow::HandleSettingChange).
|
||||
|
||||
@subsubsection port_ Closing top-level windows in wxWinCE
|
||||
|
||||
You won't get a wxCloseEvent 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.
|
||||
|
||||
@subsubsection port_ Hibernation in wxWinCE
|
||||
|
||||
Smartphone and PocketPC will send a wxEVT_HIBERNATE to the application object in low
|
||||
memory conditions. Your application should release memory and close dialogs,
|
||||
and wake up again when the next wxEVT_ACTIVATE or wxEVT_ACTIVATE_APP message is received.
|
||||
(wxEVT_ACTIVATE_APP is generated whenever a wxEVT_ACTIVATE event is received
|
||||
in Smartphone and PocketPC, since these platforms do not support WM_ACTIVATEAPP.)
|
||||
|
||||
@subsubsection port_ Hardware buttons in wxWinCE
|
||||
|
||||
Special hardware buttons are sent to a window via the wxEVT_HOTKEY event
|
||||
under Smartphone and PocketPC. You should first register each required button with
|
||||
wxWindow::RegisterHotKey, and unregister the button when you're done with it. For example:
|
||||
|
||||
@verbatim
|
||||
win->RegisterHotKey(0, wxMOD_WIN, WXK_SPECIAL1);
|
||||
win->UnregisterHotKey(0);
|
||||
@endverbatim
|
||||
|
||||
You may have to register the buttons in a wxEVT_ACTIVATE event handler
|
||||
since other applications will grab the buttons.
|
||||
|
||||
There is currently no method of finding out the names of the special
|
||||
buttons or how many there are.
|
||||
|
||||
@subsubsection port_ Dialogs in wxWinCE
|
||||
|
||||
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 wxID_OK event by default. If you wish to change this, call wxDialog::SetAffirmativeId
|
||||
with the required identifier to be used. Or, override wxDialog::DoOK (return @false to
|
||||
have wxWidgets simply call Close to dismiss the dialog).
|
||||
|
||||
Smartphone dialogs do @e not have an OK button on the caption, and are closed
|
||||
using one of the two menu buttons. You need to assign these using wxTopLevelWindow::SetLeftMenu
|
||||
and wxTopLevelWindow::SetRightMenu, for example:
|
||||
|
||||
@verbatim
|
||||
#ifdef __SMARTPHONE__
|
||||
SetLeftMenu(wxID_OK);
|
||||
SetRightMenu(wxID_CANCEL, _("Cancel"));
|
||||
#elif defined(__POCKETPC__)
|
||||
// No OK/Cancel buttons on PocketPC, OK on caption will close
|
||||
#else
|
||||
topsizer->Add( CreateButtonSizer( wxOK|wxCANCEL ), 0, wxEXPAND | wxALL, 10 );
|
||||
#endif
|
||||
@endverbatim
|
||||
|
||||
For implementing property sheets (flat tabs), use a wxNotebook with wxNB_FLAT|wxNB_BOTTOM
|
||||
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 wxPropertySheetDialog is
|
||||
provided, to show settings in the correct style on PocketPC and on other platforms.
|
||||
|
||||
Notifications (bubble HTML text with optional buttons and links) will also be
|
||||
implemented in the future for PocketPC.
|
||||
|
||||
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.
|
||||
|
||||
@subsubsection port_menus_ppc Menubars and toolbars in PocketPC
|
||||
|
||||
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.
|
||||
|
||||
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:
|
||||
|
||||
@li You must create the frame's primary toolbar with wxFrame::CreateToolBar,
|
||||
because this uses the special wxToolMenuBar class (derived from wxToolBar)
|
||||
to implement the combined toolbar and menubar. Otherwise, you can create and manage toolbars
|
||||
using the wxToolBar class as usual, for example to implement an optional
|
||||
formatting toolbar above the menubar as Pocket Word does. But don't assign
|
||||
a wxToolBar to a frame using SetToolBar - you should always use CreateToolBar
|
||||
for the main frame toolbar.
|
||||
@li Deleting and adding tools to wxToolMenuBar after Realize is called is not supported.
|
||||
@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 Adding controls to wxToolMenuBar is not supported. However, wxToolBar supports
|
||||
controls.
|
||||
|
||||
Unlike in all other ports, a wxDialog has a wxToolBar, automatically created
|
||||
for you. You may either leave it blank, or access it with wxDialog::GetToolBar
|
||||
and add buttons, then calling wxToolBar::Realize. You cannot set or recreate
|
||||
the toolbar.
|
||||
|
||||
@subsubsection port_menus_smart Menubars and toolbars in Smartphone
|
||||
|
||||
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.
|
||||
|
||||
@subsubsection port_ Closing windows in wxWinCE
|
||||
|
||||
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.
|
||||
|
||||
@subsubsection port_ Context menus in wxWinCE
|
||||
|
||||
To enable context menus in PocketPC, you currently need to call wxWindow::EnableContextMenu,
|
||||
a wxWinCE-only function. Otherwise the context menu event (wxContextMenuEvent) will
|
||||
never be sent. This API is subject to change.
|
||||
|
||||
Context menus are not supported in Smartphone.
|
||||
|
||||
@subsubsection port_ Control differences on wxWinCE
|
||||
|
||||
These controls and styles are specific to wxWinCE:
|
||||
|
||||
@li wxTextCtrl The wxTE_CAPITALIZE style causes a CAPEDIT control to
|
||||
be created, which capitalizes the first letter.
|
||||
|
||||
These controls are missing from wxWinCE:
|
||||
|
||||
@li MDI classes MDI is not supported under Windows CE.
|
||||
@li wxMiniFrame Not supported under Windows CE.
|
||||
|
||||
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.
|
||||
|
||||
Control borders on PocketPC and Smartphone should normally be specified with
|
||||
wxBORDER_SIMPLE instead of wxBORDER_SUNKEN. Controls will usually adapt
|
||||
appropriately by virtue of their GetDefaultBorder() function, but if you
|
||||
wish to specify a style explicitly you can use wxDEFAULT_CONTROL_BORDER
|
||||
which will give a simple border on PocketPC and Smartphone, and the sunken border on
|
||||
other platforms.
|
||||
|
||||
@subsubsection port_ Online help in wxWinCE
|
||||
|
||||
You can use the help controller wxWinceHelpController which controls
|
||||
simple @c .htm files, usually installed in the Windows directory.
|
||||
See the Windows CE reference for how to format the HTML files.
|
||||
|
||||
@subsubsection port_ Installing your PocketPC and Smartphone applications
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
Here are some links that may help.
|
||||
|
||||
@li A setup builder that takes CABs and builds a setup program is at
|
||||
http://www.eskimo.com/~scottlu/win/index.html.
|
||||
@li Sample installation files can be found in
|
||||
<tt>Windows CE Tools/wce420/POCKET PC 2003/Samples/Win32/AppInst</tt>.
|
||||
@li An installer generator using wxPython can be found at
|
||||
http://ppcquicksoft.iespana.es/ppcquicksoft/myinstall.html.
|
||||
@li Miscellaneous Windows CE resources can be found at
|
||||
http://www.orbworks.com/pcce/resources.html.
|
||||
@li Installer creation instructions with a setup.exe for installing to PPC can be found at
|
||||
http://www.pocketpcdn.com/articles/creatingsetup.html.
|
||||
@li Microsoft instructions are at
|
||||
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnce30/html/appinstall30.asp?frame=true
|
||||
@li Troubleshooting WinCE application installations:
|
||||
http://support.microsoft.com/default.aspx?scid=KB;en-us;q181007
|
||||
|
||||
You may also check out <tt>demos/life/setup/wince</tt> which contains
|
||||
scripts to create a PocketPC installation for ARM-based
|
||||
devices. In particular, @c build.bat builds the distribution and
|
||||
copies it to a directory called @c Deliver.
|
||||
|
||||
@subsubsection port_ wxFileDialog in PocketPC
|
||||
|
||||
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.
|
||||
|
||||
If you need a file dialog that allows access to all folders,
|
||||
you can use wxGenericFileDialog instead. You will need to include
|
||||
@c wx/generic/filedlgg.h.
|
||||
|
||||
@subsubsection port_ Embedded Visual C++ Issues
|
||||
|
||||
<b>Run-time type information</b>
|
||||
|
||||
If you wish to use runtime type information (RTTI) with eVC++ 4, you need to download
|
||||
an extra library, @c ccrtrtti.lib, and link with it. At the time of
|
||||
writing you can get it from here:
|
||||
|
||||
@verbatim
|
||||
http://support.microsoft.com/kb/830482/en-us
|
||||
@endverbatim
|
||||
|
||||
Otherwise you will get linker errors similar to this:
|
||||
|
||||
@verbatim
|
||||
wxwince26d.lib(control.obj) : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
|
||||
@endverbatim
|
||||
|
||||
<b>Windows Mobile 5.0 emulator</b>
|
||||
|
||||
Note that there is no separate emulator configuration for Windows Mobile 5.0: the
|
||||
emulator runs the ARM code directly.
|
||||
|
||||
<b>Visual Studio 2005 project files</b>
|
||||
|
||||
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.
|
||||
|
||||
When you have converted the wxWidgets workspace, edit the configuration properties
|
||||
for each configuration and in the Librarian, add a relative path ..\..\lib to
|
||||
each library path. For example:
|
||||
<tt>..\$(PlatformName)\$(ConfigurationName)\wx_mono.lib</tt>.
|
||||
|
||||
Then, for a sample you want to compile, edit the configuration properties
|
||||
and make sure
|
||||
<tt>..\..\lib\\$(PlatformName)\\$(ConfigurationName)</tt>
|
||||
is in the Linker/General/Additional Library Directories property.
|
||||
Also change the Linker/Input/Additional Dependencies 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</tt>
|
||||
(since the library names in the wxWidgets workspace were changed by VS 2005).
|
||||
|
||||
Alternately, you could could edit all the names to be identical to the original eVC++
|
||||
names, but this will probably be more fiddly.
|
||||
|
||||
@subsubsection port_ Remaining issues
|
||||
|
||||
These are some of the remaining problems to be sorted out, and features
|
||||
to be supported.
|
||||
|
||||
@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 <b>Sizer speed.</b> Particularly for dialogs containing notebooks,
|
||||
layout seems slow. Some analysis is required.
|
||||
@li <b>Notification boxes.</b> The balloon-like notification messages, and their
|
||||
icons, should be implemented. This will be quite straightforward.
|
||||
@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 WC_SIPREF control.
|
||||
@li <b>wxStaticBitmap.</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 <b>wxStaticLine.</b> Lines don't show up, and the documentation suggests that
|
||||
missing styles are implemented with WM_PAINT.
|
||||
@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 wxHtmlWindow that uses this
|
||||
control, or have a separately-named control (wxHtmlCtrl), with a syntax as close as possible
|
||||
to wxHtmlWindow.
|
||||
@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 <b>Focus.</b> In the wxPropertySheetDialog 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 <b>OK button.</b> We should allow the OK button on a dialog to be optional, perhaps
|
||||
by using wxCLOSE_BOX to indicate when the OK button should be displayed.
|
||||
@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 <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 <b>Home screen plugins.</b> Figure out how to make home screen plugins for use with wxWidgets
|
||||
applications (see http://www.codeproject.com/ce/CTodayWindow.asp 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 <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 <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.
|
||||
|
||||
|
||||
@section nativedocs Documentation for the native toolkits
|
||||
|
||||
Reference in New Issue
Block a user