Initial review of various [q-r] by Utensil Candel.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@53444 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Bryan Petty
@@ -189,7 +189,7 @@ in the distribution.
|
||||
|
||||
@subsection page_port_wxmsw_themedborders Themed borders on Windows
|
||||
|
||||
Starting with wxWidgets 2.8.5, you can specify the wxBORDER_THEME style to have wxWidgets
|
||||
Starting with wxWidgets 2.8.5, you can specify the @c 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.
|
||||
@@ -198,11 +198,11 @@ If you don't specify a border style for a wxTextCtrl in rich edit mode, wxWidget
|
||||
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.
|
||||
as wxPanel, pass the @c 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
|
||||
In general, specifying @c 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 @c wxBORDER_DEFAULT.
|
||||
This is not to be confused with specifying @c wxBORDER_NONE, which says that there should
|
||||
definitely be @e no border.
|
||||
|
||||
@subsubsection page_port_wxmsw_themedborders_details More detail on border implementation
|
||||
@@ -241,7 +241,7 @@ 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
|
||||
@code
|
||||
#if defined(__WXWINCE__)
|
||||
#define wxLARGESMALL(large,small) small
|
||||
#else
|
||||
@@ -250,7 +250,7 @@ use a macro such as this:
|
||||
|
||||
// Usage
|
||||
topsizer->Add( CreateTextSizer( message ), 0, wxALL, wxLARGESMALL(10,0) );
|
||||
@endverbatim
|
||||
@endcode
|
||||
|
||||
There is only ever one instance of a Windows CE application running,
|
||||
and wxWidgets will take care of showing the current instance and
|
||||
@@ -306,7 +306,7 @@ 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).
|
||||
accordingly (see wxTopLevelWindow::HandleSettingChange()).
|
||||
|
||||
@subsubsection page_port_wxmsw_wince_toplevel Closing top-level windows in wxWinCE
|
||||
|
||||
@@ -316,24 +316,24 @@ event to force the application to close down.
|
||||
|
||||
@subsubsection page_port_wxmsw_wince_hibernation Hibernation in wxWinCE
|
||||
|
||||
Smartphone and PocketPC will send a wxEVT_HIBERNATE to the application object in low
|
||||
Smartphone and PocketPC will send a @c 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.)
|
||||
and wake up again when the next @c wxEVT_ACTIVATE or @c wxEVT_ACTIVATE_APP message is received.
|
||||
(@c wxEVT_ACTIVATE_APP is generated whenever a @c wxEVT_ACTIVATE event is received
|
||||
in Smartphone and PocketPC, since these platforms do not support @c WM_ACTIVATEAPP.)
|
||||
|
||||
@subsubsection page_port_wxmsw_wince_hwbutt Hardware buttons in wxWinCE
|
||||
|
||||
Special hardware buttons are sent to a window via the wxEVT_HOTKEY event
|
||||
Special hardware buttons are sent to a window via the @c 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:
|
||||
wxWindow::RegisterHotKey(), and unregister the button when you're done with it. For example:
|
||||
|
||||
@verbatim
|
||||
@code
|
||||
win->RegisterHotKey(0, wxMOD_WIN, WXK_SPECIAL1);
|
||||
win->UnregisterHotKey(0);
|
||||
@endverbatim
|
||||
@endcode
|
||||
|
||||
You may have to register the buttons in a wxEVT_ACTIVATE event handler
|
||||
You may have to register the buttons in a @c wxEVT_ACTIVATE event handler
|
||||
since other applications will grab the buttons.
|
||||
|
||||
There is currently no method of finding out the names of the special
|
||||
@@ -345,15 +345,15 @@ 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
|
||||
a @c 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:
|
||||
and wxTopLevelWindow::SetRightMenu(), for example:
|
||||
|
||||
@verbatim
|
||||
@code
|
||||
#ifdef __SMARTPHONE__
|
||||
SetLeftMenu(wxID_OK);
|
||||
SetRightMenu(wxID_CANCEL, _("Cancel"));
|
||||
@@ -362,9 +362,9 @@ and wxTopLevelWindow::SetRightMenu, for example:
|
||||
#else
|
||||
topsizer->Add( CreateButtonSizer( wxOK|wxCANCEL ), 0, wxEXPAND | wxALL, 10 );
|
||||
#endif
|
||||
@endverbatim
|
||||
@endcode
|
||||
|
||||
For implementing property sheets (flat tabs), use a wxNotebook with wxNB_FLAT|wxNB_BOTTOM
|
||||
For implementing property sheets (flat tabs), use a wxNotebook with @c 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
|
||||
@@ -387,7 +387,7 @@ 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,
|
||||
@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
|
||||
@@ -402,8 +402,8 @@ or with transparency (for example, using XPMs).
|
||||
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
|
||||
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 page_port_wxmsw_wince_smart Menubars and toolbars in Smartphone
|
||||
@@ -424,7 +424,7 @@ wxID_EXIT, it will do the right thing.
|
||||
|
||||
@subsubsection page_port_wxmsw_wince_ctx Context menus in wxWinCE
|
||||
|
||||
To enable context menus in PocketPC, you currently need to call wxWindow::EnableContextMenu,
|
||||
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.
|
||||
|
||||
@@ -434,7 +434,7 @@ Context menus are not supported in Smartphone.
|
||||
|
||||
These controls and styles are specific to wxWinCE:
|
||||
|
||||
@li wxTextCtrl The wxTE_CAPITALIZE style causes a CAPEDIT control to
|
||||
@li wxTextCtrl The @c wxTE_CAPITALIZE style causes a CAPEDIT control to
|
||||
be created, which capitalizes the first letter.
|
||||
|
||||
These controls are missing from wxWinCE:
|
||||
@@ -447,9 +447,9 @@ 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
|
||||
@c wxBORDER_SIMPLE instead of @c 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
|
||||
wish to specify a style explicitly you can use @c wxDEFAULT_CONTROL_BORDER
|
||||
which will give a simple border on PocketPC and Smartphone, and the sunken border on
|
||||
other platforms.
|
||||
|
||||
@@ -569,11 +569,11 @@ icons, should be implemented. This will be quite straightforward.
|
||||
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.
|
||||
show the SIP automatically using the @c 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.
|
||||
missing styles are implemented with @c 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
|
||||
@@ -587,7 +587,7 @@ between controls. The focus handling in wxWidgets needs investigation. See in pa
|
||||
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.
|
||||
by using @c 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.
|
||||
|
||||
@@ -97,7 +97,7 @@ printing under MSW and Mac), or a wxPostScriptDC (for printing under GTK or
|
||||
generating PostScript output).
|
||||
|
||||
The @ref overview_docview "document/view framework" creates a default
|
||||
wxPrintout object for every view, calling wxView::OnDraw to achieve a
|
||||
wxPrintout object for every view, calling wxView::OnDraw() to achieve a
|
||||
prepackaged print/preview facility.
|
||||
|
||||
If your window classes have a Draw(wxDC *dc) routine to do screen rendering,
|
||||
@@ -141,7 +141,7 @@ There are two important rectangles in printing: the <em>page rectangle</em>
|
||||
defines the printable area seen by the application, and under MSW and Mac, it
|
||||
is the printable area specified by the printer. (For PostScript printing, the
|
||||
page rectangle is the entire page.) The inherited function
|
||||
wxDC::GetSize returns the page size in device pixels. The
|
||||
wxDC::GetSize() returns the page size in device pixels. The
|
||||
point (0,0) on the wxPrinterDC represents the top left corner of the page
|
||||
rectangle; that is, the page rect is given by wxRect(0, 0, w, h), where (w,h)
|
||||
are the values returned by GetSize.
|
||||
@@ -150,7 +150,7 @@ The <em>paper rectangle</em>, on the other hand, represents the entire paper
|
||||
area including the non-printable border. Thus, the coordinates of the top left
|
||||
corner of the paper rectangle will have small negative values, while the width
|
||||
and height will be somewhat larger than that of the page rectangle. The
|
||||
wxPrinterDC-specific function wxPrinterDC::GetPaperRect returns the paper
|
||||
wxPrinterDC-specific function wxPrinterDC::GetPaperRect() returns the paper
|
||||
rectangle of the given wxPrinterDC.
|
||||
|
||||
|
||||
|
||||
@@ -10,7 +10,8 @@
|
||||
|
||||
@page overview_python wxPython Overview
|
||||
|
||||
This topic was written by Robin Dunn, author of the wxPython wrapper.
|
||||
This topic was written by Robin Dunn, author of the
|
||||
<a href="http://www.python.org/">wxPython</a> wrapper.
|
||||
|
||||
@li @ref overview_python_what
|
||||
@li @ref overview_python_why
|
||||
@@ -120,19 +121,19 @@ pieces you need without having to use the GUI portions.
|
||||
There are quite a few other GUI modules available for Python, some in active
|
||||
use, some that haven't been updated for ages. Most are simple wrappers around
|
||||
some C or C++ toolkit or another, and most are not cross-platform compatible.
|
||||
See http://pypi.python.org/pypi?:action=browse&show=all&c=433 for a listing of
|
||||
a few of them.
|
||||
See <a href="http://pypi.python.org/pypi?:action=browse&show=all&c=433">this link</a>
|
||||
for a listing of a few of them.
|
||||
|
||||
|
||||
@section overview_python_using Using wxPython
|
||||
|
||||
I'm not going to try and teach the Python language here. You can do that at the
|
||||
<http://www.python.org/doc/tut/tut.html>. I'm also going to assume that you
|
||||
know a bit about wxWidgets already, enough to notice the similarities in the
|
||||
classes used.
|
||||
<a href="http://www.python.org/doc/tut/tut.html">Python Tutorial</a>. I'm also
|
||||
going to assume that you know a bit about wxWidgets already, enough to notice
|
||||
the similarities in the classes used.
|
||||
|
||||
Take a look at the following wxPython program. You can find a similar program
|
||||
in the wxPython/demo directory, named "DialogUnits.py". If your Python and
|
||||
in the @c wxPython/demo directory, named @c DialogUnits.py. If your Python and
|
||||
wxPython are properly installed, you should be able to run it by issuing this
|
||||
command:
|
||||
|
||||
@@ -221,8 +222,8 @@ python DialogUnits.py
|
||||
|
||||
At line 2 the wxPython classes, constants, and etc. are imported into the
|
||||
current module's namespace. If you prefer to reduce namespace pollution you can
|
||||
use "from wxPython import wx" and then access all the wxPython identifiers
|
||||
through the wx module, for example, "wx.wxFrame".
|
||||
use @c "from wxPython import wx" and then access all the wxPython identifiers
|
||||
through the wx module, for example, @c "wx.wxFrame".
|
||||
|
||||
At line 13 the frame's sizing and moving events are connected to methods of the
|
||||
class. These helper functions are intended to be like the event table macros
|
||||
@@ -235,13 +236,13 @@ Notice the use of @c wxDLG_PNT and @c wxDLG_SZE in lines 19-29 to convert from
|
||||
dialog units to pixels. These helpers are unique to wxPython since Python can't
|
||||
do method overloading like C++.
|
||||
|
||||
There is an @c OnCloseWindow method at line 34 but no call to EVT_CLOSE to
|
||||
There is an @c OnCloseWindow method at line 34 but no call to @c EVT_CLOSE to
|
||||
attach the event to the method. Does it really get called? The answer is, yes
|
||||
it does. This is because many of the standard events are attached to windows
|
||||
that have the associated standard method names. I have tried to follow the lead
|
||||
of the C++ classes in this area to determine what is standard but since that
|
||||
changes from time to time I can make no guarantees, nor will it be fully
|
||||
documented. When in doubt, use an EVT_*** function.
|
||||
documented. When in doubt, use an @c EVT_*** function.
|
||||
|
||||
At lines 17 to 21 notice that there are no saved references to the panel or the
|
||||
static text items that are created. Those of you who know Python might be
|
||||
@@ -250,7 +251,7 @@ scope. Do they disappear from the GUI? They don't. Remember that in wxPython
|
||||
the Python objects are just shadows of the corresponding C++ objects. Once the
|
||||
C++ windows and controls are attached to their parents, the parents manage them
|
||||
and delete them when necessary. For this reason, most wxPython objects do not
|
||||
need to have a __del__ method that explicitly causes the C++ object to be
|
||||
need to have a @c __del__ method that explicitly causes the C++ object to be
|
||||
deleted. If you ever have the need to forcibly delete a window, use the
|
||||
Destroy() method as shown on line 36.
|
||||
|
||||
@@ -300,7 +301,7 @@ spec over time.
|
||||
@li wxColour
|
||||
@li wxComboBox
|
||||
@li wxCommandEvent
|
||||
@li wxConfig
|
||||
@li wxConfigBase
|
||||
@li wxControl
|
||||
@li wxCursor
|
||||
@li wxCustomDataObject
|
||||
@@ -355,7 +356,7 @@ spec over time.
|
||||
@li wxIndividualLayoutConstraint
|
||||
@li wxInitDialogEvent
|
||||
@li wxInputStream
|
||||
@li wxInternetFSHandler
|
||||
@li @ref wxFileSystem "wxInternetFSHandler"
|
||||
@li wxJoystickEvent
|
||||
@li wxJPEGHandler
|
||||
@li wxKeyEvent
|
||||
@@ -377,7 +378,7 @@ spec over time.
|
||||
@li wxMenuItem
|
||||
@li wxMenu
|
||||
@li wxMessageDialog
|
||||
@li wxMetaFileDC
|
||||
@li wxMetafileDC
|
||||
@li wxMiniFrame
|
||||
@li wxMouseEvent
|
||||
@li wxMoveEvent
|
||||
@@ -454,7 +455,7 @@ spec over time.
|
||||
@li wxValidator
|
||||
@li wxWindowDC
|
||||
@li wxWindow
|
||||
@li wxZipFSHandler
|
||||
@li @ref wxFileSystem "wxZipFSHandler"
|
||||
|
||||
|
||||
@section overview_python_help Where to Go for Help
|
||||
|
||||
@@ -41,9 +41,10 @@ operation on it is the same.
|
||||
|
||||
@section overview_refcount_equality Object Comparison
|
||||
|
||||
The == and != operators of the reference counted classes always do a @c deep
|
||||
comparison. This means that the equality operator will return @true if two
|
||||
objects are identical and not only if they share the same data.
|
||||
The == and != operators of @ref overview_refcount_list "the reference counted classes"
|
||||
always do a <em>deep comparison</em>. This means that the equality operator
|
||||
will return @true if two objects are identical and not only if they share the
|
||||
same data.
|
||||
|
||||
Note that wxWidgets follows the <em>STL philosophy</em>: when a comparison
|
||||
operator can not be implemented efficiently (like for e.g. wxImage's ==
|
||||
@@ -90,8 +91,8 @@ operators and copy constructors since they are reference-counted:
|
||||
Note that the list above reports the objects which are reference counted in all
|
||||
ports of wxWidgets; some ports may use this technique also for other classes.
|
||||
|
||||
All the objects implement a function IsOk() to test if they are referencing valid
|
||||
data; when the objects are in uninitialized state, you can only use the IsOk() getter;
|
||||
All the objects implement a function @b IsOk() to test if they are referencing valid
|
||||
data; when the objects are in uninitialized state, you can only use the @b IsOk() getter;
|
||||
trying to call any other getter, e.g. wxBrush::GetStyle() on the ::wxNullBrush object,
|
||||
will result in an assert failure in debug builds.
|
||||
|
||||
@@ -120,7 +121,7 @@ In fact, any time you need to read the data from your wxObject-derived class,
|
||||
you will need to call this function.
|
||||
|
||||
@note Any time you need to actually modify the data placed inside your wxObject
|
||||
derived class, you must first call the wxObject::UnShare function to ensure
|
||||
derived class, you must first call the wxObject::UnShare() function to ensure
|
||||
that the modifications won't affect other instances which are eventually
|
||||
sharing your object's data.
|
||||
|
||||
|
||||
@@ -15,9 +15,9 @@ REM These not automatically copied by Doxygen because it's not
|
||||
REM used in doxygen documentation, only in our html footer.
|
||||
copy images\powered-by-wxwidgets.png out\html 2>&1 >NUL
|
||||
copy images\*logo.png out\html 2>&1 >NUL
|
||||
copy images\wxgtk\*png out\html\wxgtk 2>&1 >NUL
|
||||
copy images\wxmsw\*png out\html\wxmsw 2>&1 >NUL
|
||||
copy images\wxmac\*png out\html\wxmac 2>&1 >NUL
|
||||
copy images\wxgtk\*.png out\html\wxgtk 2>&1 >NUL
|
||||
copy images\wxmsw\*.png out\html\wxmsw 2>&1 >NUL
|
||||
copy images\wxmac\*.png out\html\wxmac 2>&1 >NUL
|
||||
copy wxwidgets.js out\html 2>&1 >NUL
|
||||
|
||||
REM this CSS is automatically copied by Doxygen because it's
|
||||
|
||||
Reference in New Issue
Block a user