Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

removed trailing whitespace in Doxygen files

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@52634 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Václav Slavík
2008-03-20 13:45:17 +00:00
parent 7df4c51f60
commit 3c4f71cc3d
184 changed files with 4902 additions and 4902 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
docs/doxygen/overviews/dataobject.h
View File

@@ -46,7 +46,7 @@
@section overview_dataobject_source The data provider (source) duties
The data provider is responsible for creating a wxDataObject containing the
The data provider is responsible for creating a wxDataObject containing the
data to be transferred. Then it should either pass it to the clipboard using
wxClipboard::SetData function or to wxDropSource and call wxDropSource::DoDragDrop
function.
@@ -69,12 +69,12 @@
@section overview_dataobject_target The data receiver (target) duties
To receive (paste in usual terminology) data from the clipboard, you should
create a wxDataObject derived class which supports the data formats you need
create a wxDataObject derived class which supports the data formats you need
and pass it as argument to wxClipboard::GetData. If it returns @false,
no data in (any of) the supported format(s) is available. If it returns @true,
the data has been successfully transferred to wxDataObject.
For drag and drop case, the wxDropTarget::OnData virtual function will be called
For drag and drop case, the wxDropTarget::OnData virtual function will be called
when a data object is dropped, from which the data itself may be requested by calling
wxDropTarget::GetData method which fills the data object.

4
docs/doxygen/overviews/datetime.h
View File

@@ -49,12 +49,12 @@
@section overview_datetime_classes All date/time classes at a glance
There are 3 main classes declared in @c wx/datetime.h: except wxDateTime itself
There are 3 main classes declared in @c wx/datetime.h: except wxDateTime itself
which represents an absolute moment in time, there are also two classes -
wxTimeSpan and wxDateSpan - which represent the intervals of time.
There are also helper classes which are used together with wxDateTime:
wxDateTimeHolidayAuthority which is used to determine whether a given date
wxDateTimeHolidayAuthority which is used to determine whether a given date
is a holiday or not and wxDateTimeWorkDays which is a derivation of this
class for which (only) Saturdays and Sundays are the holidays. See more about
these classes in the discussion of the holidays (see @ref overview_datetime_holidays).

6
docs/doxygen/overviews/dc.h
View File

@@ -11,16 +11,16 @@
@page overview_dc Device Contexts
Classes: wxBufferedDC, wxBufferedPaintDC, wxDC, wxPostScriptDC,
wxMetafileDC, wxMemoryDC, wxPrinterDC, wxScreenDC, wxClientDC,
wxMetafileDC, wxMemoryDC, wxPrinterDC, wxScreenDC, wxClientDC,
wxPaintDC, wxWindowDC.
A wxDC is a @e device context onto which graphics and text can be drawn.
The device context is intended to represent a number of output devices in a
The device context is intended to represent a number of output devices in a
generic way, with the same API being used throughout.
Some device contexts are created temporarily in order to draw on a window.
This is @true of wxScreenDC, wxClientDC, wxPaintDC, and wxWindowDC.
The following describes the differences between these device contexts and
The following describes the differences between these device contexts and
when you should use them.
@li @b wxScreenDC. Use this to paint on the screen, as opposed to an individual window.

14
docs/doxygen/overviews/debugging.h
View File

@@ -22,7 +22,7 @@
@li @ref overview_debugging_dbgctx
@li @ref overview_debugging_dbgmacros
@li @ref overview_debugging_logging
@li @ref overview_debugging_dbgctx2
@li @ref overview_debugging_dbgctx2
<hr>
@@ -31,7 +31,7 @@
@section overview_debugging_dbgctx wxDebugContext
wxDebugContext is a class that never gets instantiated, but ties together
various static functions and variables. It allows you to dump all objects to that stream,
various static functions and variables. It allows you to dump all objects to that stream,
write statistics about object allocation, and check memory for errors.
It is good practice to define a wxObject::Dump member function for each class you derive
@@ -47,9 +47,9 @@
and compiler -- some systems don't allow all memory logging to be enabled). See the
memcheck sample for example of usage.
For wxDebugContext to do its work, the @e new and @e delete operators for wxObject
have been redefined to store extra information about dynamically allocated objects
(but not statically declared objects).
For wxDebugContext to do its work, the @e new and @e delete operators for wxObject
have been redefined to store extra information about dynamically allocated objects
(but not statically declared objects).
This slows down a debugging version of an application, but can
find difficult-to-detect memory leaks (objects are not
@@ -64,7 +64,7 @@
@endcode
All occurrences of 'new' in wxWidgets and your own application will use
the overridden form of the operator with two extra arguments. This means that
the overridden form of the operator with two extra arguments. This means that
the debugging output (and error messages reporting memory problems) will tell you what
file and on what line you allocated the object. Unfortunately not all
compilers allow this definition to work properly, but most do.
@@ -98,7 +98,7 @@
@section overview_debugging_logging Logging functions
You can use the wxLogDebug and wxLogTrace functions to output debugging information in
You can use the wxLogDebug and wxLogTrace functions to output debugging information in
debug mode; it will do nothing for non-debugging code.

46
docs/doxygen/overviews/dialog.h
View File

@@ -37,29 +37,29 @@
@section overview_dialog_autoscrolling Automatic scrolling dialogs
As an ever greater variety of mobile hardware comes to market, it becomes more
imperative for wxWidgets applications to adapt to these platforms without putting
As an ever greater variety of mobile hardware comes to market, it becomes more
imperative for wxWidgets applications to adapt to these platforms without putting
too much burden on the programmer. One area where wxWidgets can help is in adapting
dialogs for the lower resolution screens that inevitably accompany a smaller form factor.
wxDialog therefore supplies a global wxDialogLayoutAdapter class that implements
wxDialog therefore supplies a global wxDialogLayoutAdapter class that implements
automatic scrolling adaptation for most sizer-based custom dialogs.
Many applications should therefore be able to adapt to small displays with little
Many applications should therefore be able to adapt to small displays with little
or no work, as far as dialogs are concerned.
By default this adaptation is off. To switch scrolling adaptation on globally in
By default this adaptation is off. To switch scrolling adaptation on globally in
your application, call the static function wxDialog::EnableLayoutAdaptation passing @true.
You can also adjust adaptation on a per-dialog basis by calling
wxDialog::SetLayoutAdaptationMode with one of @c wxDIALOG_ADAPTATION_MODE_DEFAULT
wxDialog::SetLayoutAdaptationMode with one of @c wxDIALOG_ADAPTATION_MODE_DEFAULT
(use the global setting), @c wxDIALOG_ADAPTATION_MODE_ENABLED or @c wxDIALOG_ADAPTATION_MODE_DISABLED.
The last two modes override the global adaptation setting.
With adaptation enabled, if the display size is too small for the dialog, wxWidgets (or rather the
standard adapter class wxStandardDialogLayoutAdapter) will make part of the dialog scrolling,
leaving standard buttons in a non-scrolling part at the bottom of the dialog.
This is done as follows, in wxDialogLayoutAdapter::DoLayoutAdaptation called from
This is done as follows, in wxDialogLayoutAdapter::DoLayoutAdaptation called from
within wxDialog::Show or wxDialog::ShowModal:
@li If wxDialog::GetContentWindow returns a window derived from wxBookCtrlBase,
@li If wxDialog::GetContentWindow returns a window derived from wxBookCtrlBase,
the pages are made scrollable and no other adaptation is done.
@li wxWidgets looks for a wxStdDialogButtonSizer and uses it for the non-scrolling part.
@li If that search failed, wxWidgets looks for a horizontal wxBoxSizer with one or more
@@ -67,17 +67,17 @@
@li If that search failed too, wxWidgets finds 'loose' standard buttons (in any kind of sizer)
and adds them to a wxStdDialogButtonSizer.
If no standard buttons were found, the whole dialog content will scroll.
@li All the children apart from standard buttons are reparented onto a new wxScrolledWindow
object, using the old top-level sizer for the scrolled window and creating a new top-level
@li All the children apart from standard buttons are reparented onto a new wxScrolledWindow
object, using the old top-level sizer for the scrolled window and creating a new top-level
sizer to lay out the scrolled window and standard button sizer.
@subsection overview_dialog_autoscrolling_custom Customising scrolling adaptation
In addition to switching adaptation on and off globally and per dialog,
In addition to switching adaptation on and off globally and per dialog,
you can choose how aggressively wxWidgets will search for standard buttons by setting
wxDialog::SetLayoutAdaptationLevel. By default, all the steps described above will be
performed but by setting the level to 1, for example, you can choose to only look for
wxDialog::SetLayoutAdaptationLevel. By default, all the steps described above will be
performed but by setting the level to 1, for example, you can choose to only look for
wxStdDialogButtonSizer.
You can use wxDialog::AddMainButtonId to add identifiers for buttons that should also be
@@ -88,7 +88,7 @@
the functions CanDoLayoutAdaptation and DoLayoutAdaptation to test for adaptation applicability
and perform the adaptation.
You can also override wxDialog::CanDoLayoutAdaptation and wxDialog::DoLayoutAdaptation
You can also override wxDialog::CanDoLayoutAdaptation and wxDialog::DoLayoutAdaptation
in a class derived from wxDialog.
@@ -100,13 +100,13 @@
@li The dialog doesn't use sizers.
@li The dialog implementation makes assumptions about the window hierarchy,
for example getting the parent of a control and casting to the dialog class.
@li The dialog does custom painting and/or event handling not handled by the scrolled window.
@li The dialog does custom painting and/or event handling not handled by the scrolled window.
If this problem can be solved globally, you can derive a new adapter class from
wxStandardDialogLayoutAdapter and override its CreateScrolledWindow function to return
wxStandardDialogLayoutAdapter and override its CreateScrolledWindow function to return
an instance of your own class.
@li The dialog has unusual layout, for example a vertical sizer containing a mixture of
@li The dialog has unusual layout, for example a vertical sizer containing a mixture of
standard buttons and other controls.
@li The dialog makes assumptions about the sizer hierarchy, for example to show or hide
@li The dialog makes assumptions about the sizer hierarchy, for example to show or hide
children of the top-level sizer. However, the original sizer hierarchy will still hold
until Show or ShowModal is called.
@@ -115,19 +115,19 @@
@li avoiding the above situations and assumptions;
@li using wxStdDialogButtonSizer;
@li only making assumptions about hierarchy immediately after the dialog is created;
@li using an intermediate sizer under the main sizer, a @false top-level sizer that
@li using an intermediate sizer under the main sizer, a @false top-level sizer that
can be relied on to exist for the purposes of manipulating child sizers and windows;
@li overriding wxDialog::GetContentWindow to return a book control if your dialog implements
@li overriding wxDialog::GetContentWindow to return a book control if your dialog implements
pages: wxWidgets will then only make the pages scrollable.
@subsection overview_dialog_propertysheet wxPropertySheetDialog and wxWizard
Adaptation for wxPropertySheetDialog is always done by simply making the pages
scrollable, since wxDialog::GetContentWindow returns the dialog's book control and
Adaptation for wxPropertySheetDialog is always done by simply making the pages
scrollable, since wxDialog::GetContentWindow returns the dialog's book control and
this is handled by the standard layout adapter.
wxWizard uses its own CanDoLayoutAdaptation and DoLayoutAdaptation functions rather
wxWizard uses its own CanDoLayoutAdaptation and DoLayoutAdaptation functions rather
than the global adapter: again, only the wizard pages are made scrollable.
*/

14
docs/doxygen/overviews/dnd.h
View File

@@ -29,22 +29,22 @@
@li @b Preparation: First of all, a data object must be created and
initialized with the data you wish to drag. For example:
@code
wxTextDataObject my_data("This text will be dragged.");
@endcode
@li <b>Drag start</b>: To start the dragging process (typically in response to a
mouse click) you must call wxDropSource::DoDragDrop like this:
@code
wxDropSource dragSource( this );
dragSource.SetData( my_data );
wxDragResult result = dragSource.DoDragDrop( true );
@endcode
@li @b Dragging: The call to DoDragDrop() blocks the program until the user releases
the mouse button (unless you override the wxDropSource::GiveFeedback function to
@li @b Dragging: The call to DoDragDrop() blocks the program until the user releases
the mouse button (unless you override the wxDropSource::GiveFeedback function to
do something special). When the mouse moves in a window of a program which understands
the same drag-and-drop protocol (any program under Windows or any program supporting
the XDnD protocol under X Windows), the corresponding wxDropTarget methods
@@ -56,7 +56,7 @@
@code
switch (result)
{
case wxDragCopy:
case wxDragCopy:
// copy the data
break;
case wxDragMove:
@@ -73,7 +73,7 @@
follow the instructions below:
@li @b Initialization: For a window to be a drop target, it needs to have
an associated wxDropTarget object. Normally, you will call wxWindow::SetDropTarget
an associated wxDropTarget object. Normally, you will call wxWindow::SetDropTarget
during window creation associating your drop target with it. You must derive a class
from wxDropTarget and override its pure virtual methods. Alternatively, you may
derive from wxTextDropTarget or wxFileDropTarget and override their OnDropText()
@@ -83,7 +83,7 @@
asks the associated wxDropTarget object if it accepts the data. For this,
a wxDataObject must be associated with the drop target and this data object will
be responsible for the format negotiation between the drag source and the drop target.
If all goes well, then wxDropTarget::OnData will get called and the wxDataObject belonging
If all goes well, then wxDropTarget::OnData will get called and the wxDataObject belonging
to the drop target can get filled with data.
@li <b>The end</b>: After processing the data, DoDragDrop() returns either

28
docs/doxygen/overviews/docview.h
View File

@@ -10,7 +10,7 @@
@page overview_docview Document/View Framework
Classes: wxDocument, wxView, wxDocTemplate, wxDocManager, wxDocParentFrame,
Classes: wxDocument, wxView, wxDocTemplate, wxDocManager, wxDocParentFrame,
wxDocChildFrame, wxDocMDIParentFrame, wxDocMDIChildFrame,
wxCommand, wxCommandProcessor
@@ -25,7 +25,7 @@
If a document's data changes, all views should be updated to reflect the change.
The framework can provide many user-interface elements based on this model.
Once you have defined your own classes and the relationships between them, the framework
Once you have defined your own classes and the relationships between them, the framework
takes care of popping up file selectors, opening and closing files, asking the user to save
modifications, routing menu commands to appropriate (possibly default) code, even
some default print/preview functionality and support for command undo/redo.
@@ -33,13 +33,13 @@
The framework is highly modular, allowing overriding and replacement of functionality
and objects to achieve more than the default behaviour.
These are the overall steps involved in creating an application based on the
These are the overall steps involved in creating an application based on the
document/view framework:
@li Define your own document and view classes, overriding a minimal set of
member functions e.g. for input/output, drawing and initialization.
@li Define any subwindows (such as a scrolled window) that are needed for the view(s).
You may need to route some events to views or documents, for example OnPaint needs
You may need to route some events to views or documents, for example OnPaint needs
to be routed to wxView::OnDraw.
@li Decide what style of interface you will use: Microsoft's MDI (multiple
document child frames surrounded by an overall frame), SDI (a separate, unconstrained frame
@@ -136,7 +136,7 @@
Class: wxView
The wxView class can be used to model the viewing and editing component of
an application's file-based data. It is part of the document/view framework
an application's file-based data. It is part of the document/view framework
supported by wxWidgets, and cooperates with the wxDocument, wxDocTemplate
and wxDocManager classes.
@@ -179,7 +179,7 @@
document templates, but each would be passed a different view class. When
the user clicks on the Open menu item, the file selector is displayed
with a list of possible file filters -- one for each wxDocTemplate. Selecting
the filter selects the wxDocTemplate, and when a file is selected, that template
the filter selects the wxDocTemplate, and when a file is selected, that template
will be used for creating a document and view.
For the case where an application has one document type and one view type,
@@ -192,7 +192,7 @@
See the example application in @c samples/docview.
To use the wxDocTemplate class, you do not need to derive a new class.
Just pass relevant information to the constructor including CLASSINFO(YourDocumentClass)
Just pass relevant information to the constructor including CLASSINFO(YourDocumentClass)
and CLASSINFO(YourViewClass) to allow dynamic instance creation.
If you do not wish to use the wxWidgets method of creating document
@@ -210,10 +210,10 @@
The wxDocManager class is part of the document/view framework supported by wxWidgets,
and cooperates with the wxView, wxDocument and wxDocTemplate classes.
A wxDocManager instance coordinates documents, views and document templates.
It keeps a list of document and template instances, and much functionality is routed
through this object, such as providing selection and file dialogs.
The application can use this class 'as is' or derive a class and override some members
A wxDocManager instance coordinates documents, views and document templates.
It keeps a list of document and template instances, and much functionality is routed
through this object, such as providing selection and file dialogs.
The application can use this class 'as is' or derive a class and override some members
to extend or change the functionality.
Create an instance of this class near the beginning of your application initialization,
@@ -271,13 +271,13 @@
to derive from it to allow different behaviour, such as popping up a scrolling
list of files.
By calling wxFileHistory::UseMenu() you can associate a file menu with the file history.
By calling wxFileHistory::UseMenu() you can associate a file menu with the file history.
The menu will then be used for appending filenames that are added to the history.
Please notice that currently if the history already contained filenames when UseMenu()
Please notice that currently if the history already contained filenames when UseMenu()
is called (e.g. when initializing a second MDI child frame), the menu is not automatically
initialized with the existing filenames in the history and so you need to call
wxFileHistory::AddFilesToMenu() after UseMenu() explicitly in order to initialize the menu with
wxFileHistory::AddFilesToMenu() after UseMenu() explicitly in order to initialize the menu with
the existing list of MRU files (otherwise an assertion failure is raised in debug builds).
The filenames are appended using menu identifiers in the range @c wxID_FILE1 to @c wxID_FILE9.

16
docs/doxygen/overviews/eventhandling.h
View File

@@ -63,9 +63,9 @@
member function in a derived class will not have any effect. These member
functions take an event argument, and the class of event differs according to
the type of event and the class of the originating window. For size events,
wxSizeEvent is used. For menu commands and most control commands
wxSizeEvent is used. For menu commands and most control commands
(such as button presses), wxCommandEvent is used. When controls get more
complicated, then specific event classes are used, such as wxTreeEvent for
complicated, then specific event classes are used, such as wxTreeEvent for
events from wxTreeCtrl windows.
As well as the event table in the implementation file, there must also be a
@@ -152,9 +152,9 @@
@li If the object is a wxWindow, @b ProcessEvent is recursively called on the window's
wxValidator. If this returns @true, the function exits.
@li @b SearchEventTable is called for this event handler. If this fails, the base
class table is tried, and so on until no more tables exist or an appropriate
class table is tried, and so on until no more tables exist or an appropriate
function was found, in which case the function exits.
@li The search is applied down the entire chain of event handlers (usually the chain has
@li The search is applied down the entire chain of event handlers (usually the chain has
a length of one). If this succeeds, the function exits.
@li If the object is a wxWindow and the event is set to set to propagate (in the library only
wxCommandEvent based events are set to propagate), @b ProcessEvent is recursively applied
@@ -232,13 +232,13 @@
While generically wxEvents can be generated both by user
actions (e.g. resize of a wxWindow) and by calls to functions
(e.g. wxWindow::SetSize), wxWidgets controls normally send wxCommandEvent-derived
(e.g. wxWindow::SetSize), wxWidgets controls normally send wxCommandEvent-derived
events only for the user-generated events. The only @b exceptions to this rule are:
@li wxNotebook::AddPage: No event-free alternatives
@li wxNotebook::AdvanceSelection: No event-free alternatives
@li wxNotebook::DeletePage: No event-free alternatives
@li wxNotebook::SetSelection: Use wxNotebook::ChangeSelection instead, as
@li wxNotebook::SetSelection: Use wxNotebook::ChangeSelection instead, as
wxNotebook::SetSelection is deprecated
@li wxTreeCtrl::Delete: No event-free alternatives
@li wxTreeCtrl::DeleteAllItems: No event-free alternatives
@@ -255,7 +255,7 @@
In fact, you don't have to derive a new class from a window class
if you don't want to. You can derive a new class from wxEvtHandler instead,
defining the appropriate event table, and then call wxWindow::SetEventHandler
defining the appropriate event table, and then call wxWindow::SetEventHandler
(or, preferably, wxWindow::PushEventHandler) to make this
event handler the object that responds to events. This way, you can avoid
a lot of class derivation, and use instances of the same event handler class (but different
@@ -461,7 +461,7 @@
@row2col{EVT_CUSTOM_RANGE(event\, id1\, id2\, func),
The same as EVT_CUSTOM, but responds to a range of window identifiers.}
@row2col{EVT_COMMAND(id\, event\, func),
The same as EVT_CUSTOM, but expects a member function with a
The same as EVT_CUSTOM, but expects a member function with a
wxCommandEvent argument.}
@row2col{EVT_COMMAND_RANGE(id1\, id2\, event\, func),
The same as EVT_CUSTOM_RANGE, but

2
docs/doxygen/overviews/filesystem.h
View File

@@ -36,7 +36,7 @@
Its main methods are ChangePathTo() and OpenFile(). This class
is most often used by the end user.
@li The wxFileSystemHandler is the core
of virtual file systems mechanism. You can derive your own handler and pass
of virtual file systems mechanism. You can derive your own handler and pass
it to the VFS mechanism. You can derive your own handler and pass it to
wxFileSystem's AddHandler() method. In the new handler you only need to
override the OpenFile() and CanOpen() methods.

4
docs/doxygen/overviews/font.h
View File

@@ -26,14 +26,14 @@
@beginDefList
@itemdef{Point size, This is the standard way of referring to text size.}
@itemdef{Family,
@itemdef{Family,
Supported families are:
@b wxDEFAULT, @b wxDECORATIVE, @b wxROMAN, @b wxSCRIPT, @b wxSWISS, @b wxMODERN.
@b wxMODERN is a fixed pitch font; the others are either fixed or variable pitch.}
@itemdef{Style, The value can be @b wxNORMAL, @b wxSLANT or @b wxITALIC.}
@itemdef{Weight, The value can be @b wxNORMAL, @b wxLIGHT or @b wxBOLD.}
@itemdef{Underlining, The value can be @true or @false.}
@itemdef{Face name,
@itemdef{Face name,
An optional string specifying the actual typeface to be used. If @NULL,
a default typeface will chosen based on the family.}
@itemdef{Encoding,

4
docs/doxygen/overviews/fontencoding.h
View File

@@ -21,8 +21,8 @@
(see @ref overview_unicode).
Font encoding support is ensured by several classes:
wxFont itself, but also wxFontEnumerator and wxFontMapper. wxFont encoding
support is reflected by a (new) constructor parameter @e encoding which takes
wxFont itself, but also wxFontEnumerator and wxFontMapper. wxFont encoding
support is reflected by a (new) constructor parameter @e encoding which takes
one of the following values (elements of enumeration type @c wxFontEncoding):
@beginDefList

2
docs/doxygen/overviews/helloworld.h
View File

@@ -54,7 +54,7 @@
giving it a menu and a status bar in its constructor. Also, any class
that wishes to respond to any "event" (such as mouse clicks or
messages from the menu or a button) must declare an event table
using the macro below.
using the macro below.
Finally, the way to react to such events must be done in "handlers".
In our sample, we react to two menu items, one for "Quit" and one for

50
docs/doxygen/overviews/html.h
View File

@@ -16,7 +16,7 @@
wxHTML can be used as a generic rich text viewer - for example to display
a nice About Box (like those of GNOME apps) or to display the result of
database searching. There is a wxFileSystem class which allows you to use
database searching. There is a wxFileSystem class which allows you to use
your own virtual file systems.
wxHtmlWindow supports tag handlers. This means that you can easily
@@ -60,7 +60,7 @@
@endcode
@subsection overview_html_quickstart_disphelp Displaying Help
See wxHtmlHelpController.
@subsection overview_html_quickstart_settingup Setting up wxHtmlWindow
@@ -113,30 +113,30 @@
wxHtmlPrintout, normal wxWidgets printout class.
And finally there is the low level class wxHtmlDCRenderer which you can use to
render HTML into a rectangular area on any DC.
render HTML into a rectangular area on any DC.
It supports rendering into multiple rectangles with the same
width. (The most common use of this is placing one rectangle on each page or
width. (The most common use of this is placing one rectangle on each page or
printing into two columns.)
@section overview_html_helpformats Help Files Format
wxHTML library uses a reduced version of MS HTML Workshop format.
Tex2RTF can produce these files when generating HTML, if you set
Tex2RTF can produce these files when generating HTML, if you set
@b htmlWorkshopFiles to @true in your tex2rtf.ini file.
(See wxHtmlHelpController for help controller description.)
A @b book consists of three files: the header file, the contents file
A @b book consists of three files: the header file, the contents file
and the index file.
You can make a regular zip archive of these files, plus the HTML and any
image files, for wxHTML (or helpview) to read; and the @c .zip file can
You can make a regular zip archive of these files, plus the HTML and any
image files, for wxHTML (or helpview) to read; and the @c .zip file can
optionally be renamed to @c .htb.
@subsection overview_html_helpformats_hhp Header file (.hhp)
The header file must contain these lines (and may contain additional lines
The header file must contain these lines (and may contain additional lines
which are ignored):
@code
@@ -212,8 +212,8 @@
@endcode
@subsection overview_html_helpformats_hhk Index file (.hhk)
Index files have same format as contents file except that ID params are ignored
Index files have same format as contents file except that ID params are ignored
and sublists are @b not allowed.
@@ -222,7 +222,7 @@
The wxHTML library provides a mechanism for reading and displaying
files of many different file formats.
wxHtmlWindow::LoadPage can load not only HTML files but any known file.
wxHtmlWindow::LoadPage can load not only HTML files but any known file.
To make a file type known to wxHtmlWindow you must create a wxHtmlFilter filter and
register it using wxHtmlWindow::AddFilter.
@@ -251,15 +251,15 @@
@subsection overview_html_cells_conttaghandler Using Containers in Tag Handler
wxHtmlWinParser provides a user-friendly way of managing containers.
wxHtmlWinParser provides a user-friendly way of managing containers.
It is based on the idea of opening and closing containers.
Use wxHtmlWinParser::OpenContainer to open new a container @e within an already
Use wxHtmlWinParser::OpenContainer to open new a container @e within an already
opened container.
This new container is a @e sub-container of the old one. (If you want to create a
This new container is a @e sub-container of the old one. (If you want to create a
new container with the same depth level you can call @c CloseContainer(); OpenContainer();.)
Use wxHtmlWinParser::CloseContainer to close the container.
Use wxHtmlWinParser::CloseContainer to close the container.
This doesn't create a new container with same depth level but it returns "control"
to the parent container. See explanation:
@@ -323,7 +323,7 @@
@li Parse text between the tag and paired ending tag (if present)
@li Restore original parser state
See wxHtmlWinParser for methods for modifying parser's state.
See wxHtmlWinParser for methods for modifying parser's state.
In general you can do things like opening/closing containers, changing colors, fonts etc.
@subsection overview_html_handlers_custom Providing own tag handlers
@@ -346,7 +346,7 @@
for details). Handler definition must start with @b TAG_HANDLER_BEGIN macro
and end with @b TAG_HANDLER_END macro.
I strongly recommend to have a look at @e include/wxhtml/mod_templ.h file.
I strongly recommend to have a look at @e include/wxhtml/mod_templ.h file.
Otherwise you won't understand the structure of macros.
See macros reference:
@@ -360,7 +360,7 @@
@li @b TAG_HANDLER_VARS:
This macro starts block of variables definitions. (Variables are identical
to class attributes.) Example:
@code
TAG_HANDLER_BEGIN(VARS_ONLY, "CRAZYTAG")
TAG_HANDLER_VARS
@@ -368,14 +368,14 @@
wxString something_else;
TAG_HANDLER_END(VARS_ONLY)
@endcode
This macro is used only in rare cases.
@li @b TAG_HANDLER_CONSTR(@e name):
This macro supplies object constructor. @e name is same name as the one
from TAG_HANDLER_BEGIN macro. Body of constructor follow after
this macro (you must use { and } ). Example:
@code
TAG_HANDLER_BEGIN(VARS2, "CRAZYTAG")
TAG_HANDLER_VARS
@@ -386,7 +386,7 @@
} // !!!!!!
TAG_HANDLER_END(VARS2)
@endcode
Never used in wxHTML :-)
@li @b TAG_HANDLER_PROC(@e varib):
@@ -395,7 +395,7 @@
@e tag. Body of method follows after this macro.
Note than you must use { and } !
Example:
@code
TAG_HANDLER_BEGIN(TITLE, "TITLE")
TAG_HANDLER_PROC(tag)
@@ -423,7 +423,7 @@
@li @b TAGS_MODULE_END(@e modname):
Ends the definition of module.
Example:
@code
TAGS_MODULE_BEGIN(Examples)
TAGS_MODULE_ADD(VARS_ONLY)
@@ -442,7 +442,7 @@
Following tables list all tags known to wxHTML, together with supported parameters.
A tag has general form of @c tagname param_1 param_2 ... param_n where param_i is
either @c paramname="paramvalue" or @c paramname=paramvalue - these two are equivalent.
either @c paramname="paramvalue" or @c paramname=paramvalue - these two are equivalent.
Unless stated otherwise, wxHTML is case-insensitive.
@subsection overview_html_supptags_commonvalues Table of common parameter values

10
docs/doxygen/overviews/sizer.h
View File

@@ -295,7 +295,7 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
{
wxBoxSizer *topsizer = new wxBoxSizer( wxVERTICAL );
// create text ctrl with minimal size 100x60 that is horizontally and
// create text ctrl with minimal size 100x60 that is horizontally and
// vertically stretchable with a border width of 10
topsizer->Add(
new wxTextCtrl( this, -1, "My text.", wxDefaultPosition, wxSize(100,60), wxTE_MULTILINE),
@@ -303,20 +303,20 @@ MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
wxBoxSizer *button_sizer = new wxBoxSizer( wxHORIZONTAL );
//create two buttons that are horizontally unstretchable,
//create two buttons that are horizontally unstretchable,
// with an all-around border with a width of 10 and implicit top alignment
button_sizer->Add(
new wxButton( this, wxID_OK, "OK" ),
wxSizerFlags(0).Align().Border(wxALL, 10));
wxSizerFlags(0).Align().Border(wxALL, 10));
button_sizer->Add(
new wxButton( this, wxID_CANCEL, "Cancel" ),
wxSizerFlags(0).Align().Border(wxALL, 10));
wxSizerFlags(0).Align().Border(wxALL, 10));
//create a sizer with no border and centered horizontally
topsizer->Add(
button_sizer,
wxSizerFlags(0).Center() );
wxSizerFlags(0).Center() );
SetSizerAndFit(topsizer); // use the sizer for layout and set size and hints
}

2
docs/doxygen/overviews/stream.h
View File

@@ -94,7 +94,7 @@ if (in_stream.Read(data, nb_datas).LastError() != wxSTREAM_NOERROR) {
// You can also get the last number of bytes REALLY put into the buffer.
size_t really_read = in_stream.LastRead();
// Ok, moves to the beginning of the stream. SeekI returns the last position
// Ok, moves to the beginning of the stream. SeekI returns the last position
// in the stream counted from the beginning.
off_t old_position = in_stream.SeekI(0, wxFromBeginning);

4
docs/doxygen/overviews/xrc.h
View File

@@ -466,7 +466,7 @@ initialized.
A simple example will help understand how the scheme works. Suppose you have a
XRC file defining a top level window @c TestWnd_Base, which subclasses wxFrame
(any other class like @c wxDialog will do also), and has subwidgets wxTextCtrl A
(any other class like @c wxDialog will do also), and has subwidgets wxTextCtrl A
and wxButton B.
The XRC file and corresponding class definition in the header file will be
@@ -624,7 +624,7 @@ wxObject *MyControlXmlHandler::DoCreateResource()
// do most of your work.
// If e.g. the MyControl::Create function looks like:
//
// bool MyControl::Create(wxWindow *parent, int id,
// bool MyControl::Create(wxWindow *parent, int id,
// const wxBitmap &first, const wxPoint &posFirst,
// const wxBitmap &second, const wxPoint &posSecond,
// const wxString &theTitle, const wxFont &titleFont,