@section page_topics_starting Starting with wxWidgets
- @li @subpage referencenotes_overview
- @li @subpage roughguide_overview
- @li @subpage helloworld_overview
- @li @subpage samples_overview
- @li @subpage python_overview
+ @li @subpage overview_referencenotes
+ @li @subpage overview_roughguide
+ @li @subpage overview_helloworld
+ @li @subpage overview_samples
+ @li @subpage overview_python
@section page_topics_programming Programming with wxWidgets
- @li @subpage backwardcompatibility_overview
- @li @subpage runtimeclass_overview
- @li @subpage trefcount_overview
- @li @subpage app_overview
- @li @subpage unicode_overview
- @li @subpage mbconvclasses_overview
- @li @subpage internationalization_overview
- @li @subpage nonenglish_overview
- @li @subpage debugging_overview
- @li @subpage log_overview
- @li @subpage eventhandling_overview
- @li @subpage exceptions_overview
- @li @subpage windowstyles_overview
- @li @subpage windowdeletion_overview
- @li @subpage windowids_overview
- @li @subpage envvars_overview
+ @li @subpage overview_backwardcompat
+ @li @subpage overview_runtimeclass
+ @li @subpage overview_trefcount
+ @li @subpage overview_app
+ @li @subpage overview_unicode
+ @li @subpage overview_mbconvclasses
+ @li @subpage overview_internationalization
+ @li @subpage overview_nonenglish
+ @li @subpage overview_debugging
+ @li @subpage overview_log
+ @li @subpage overview_eventhandling
+ @li @subpage overview_exceptions
+ @li @subpage overview_windowstyles
+ @li @subpage overview_windowdeletion
+ @li @subpage overview_windowids
+ @li @subpage overview_envvars
@section page_topics_nongui Overviews of non-GUI classes
- @li @subpage string_overview
- @li @subpage bufferclasses_overview
- @li @subpage datetime_overview
- @li @subpage container_overview
- @li @subpage file_overview
- @li @subpage stream_overview
- @li @subpage thread_overview
- @li @subpage config_overview
- @li @subpage fs_overview
- @li @subpage resyn_overview
- @li @subpage arc_overview
- @li @subpage ipc_overview
+ @li @subpage overview_string
+ @li @subpage overview_bufferclasses
+ @li @subpage overview_datetime
+ @li @subpage overview_container
+ @li @subpage overview_file
+ @li @subpage overview_stream
+ @li @subpage overview_thread
+ @li @subpage overview_config
+ @li @subpage overview_fs
+ @li @subpage overview_resyn
+ @li @subpage overview_arc
+ @li @subpage overview_ipc
@section page_topics_drawing Drawing related classes
- @li @subpage dc_overview
- @li @subpage bitmap_overview
- @li @subpage font_overview
- @li @subpage fontencoding_overview
- @li @subpage printing_overview
- @li @subpage unixprinting_overview
+ @li @subpage overview_dc
+ @li @subpage overview_bitmap
+ @li @subpage overview_font
+ @li @subpage overview_fontencoding
+ @li @subpage overview_printing
+ @li @subpage overview_unixprinting
@section page_topics_gui Overviews of GUI classes
- @li @subpage sizer_overview
- @li @subpage xrc_overview
- @li @subpage windowsizing_overview
- @li @subpage scrolling_overview
- @li @subpage dialog_overview
- @li @subpage validator_overview
- @li @subpage dataobject_overview
- @li @subpage dnd_overview
- @li @subpage constraints_overview
+ @li @subpage overview_sizer
+ @li @subpage overview_xrc
+ @li @subpage overview_windowsizing
+ @li @subpage overview_scrolling
+ @li @subpage overview_dialog
+ @li @subpage overview_validator
+ @li @subpage overview_dataobject
+ @li @subpage overview_dnd
+ @li @subpage overview_constraints
@section page_topics_indivctrl Overviews of individual controls
- @li @subpage html_overview
- @li @subpage richtextctrl_overview
- @li @subpage aui_overview
- @li @subpage commondialogs_overview
- @li @subpage toolbar_overview
- @li @subpage grid_overview
- @li @subpage treectrl_overview
- @li @subpage listctrl_overview
- @li @subpage splitterwindow_overview
- @li @subpage imagelist_overview
- @li @subpage bookctrl_overview
- @li @subpage tips_overview
- @li @subpage docview_overview
+ @li @subpage overview_html
+ @li @subpage overview_richtextctrl
+ @li @subpage overview_aui
+ @li @subpage overview_commondialogs
+ @li @subpage overview_toolbar
+ @li @subpage overview_grid
+ @li @subpage overview_treectrl
+ @li @subpage overview_listctrl
+ @li @subpage overview_splitterwindow
+ @li @subpage overview_imagelist
+ @li @subpage overview_bookctrl
+ @li @subpage overview_tips
+ @li @subpage overview_docview
*/
/////////////////////////////////////////////////////////////////////////////
-// Name: app
+// Name: app.h
// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
/*!
- @page app_overview wxApp overview
+ @page overview_app wxApp overview
Classes: #wxApp
A wxWidgets application does not have a @e main procedure; the equivalent is the
#OnInit member defined for a class derived from wxApp.
+
@e OnInit will usually create a top window as a bare minimum.
Unlike in earlier versions of wxWidgets, OnInit does not return a frame. Instead it
- returns a boolean value which indicates whether processing should continue (@true) or not (@false).
- You call wxApp::SetTopWindow to let wxWidgets know
- about the top window.
+ returns a boolean value which indicates whether processing should continue (@true)
+ or not (@false). You call wxApp::SetTopWindow to let wxWidgets know about the top window.
+
Note that the program's command line arguments, represented by @e argc
and @e argv, are available from within wxApp member functions.
+
An application closes by destroying all windows. Because all frames must
be destroyed for the application to exit, it is advisable to use parent
frames wherever possible when creating new frames, so that deleting the
top level frame will automatically delete child frames. The alternative
is to explicitly delete child frames in the top-level frame's #wxCloseEvent
handler.
+
In emergencies the #wxExit function can be called to kill the
application however normally the application shuts down automatically,
- @ref appshutdown_overview.
+ see @ref overview_app_shutdown.
+
An example of defining an application follows:
@code
}
@endcode
- Note the use of IMPLEMENT_APP(appClass), which allows wxWidgets to dynamically create an instance of the application object
- at the appropriate point in wxWidgets initialization. Previous versions of wxWidgets used
- to rely on the creation of a global application object, but this is no longer recommended,
- because required global initialization may not have been performed at application object
- construction time.
- You can also use DECLARE_APP(appClass) in a header file to declare the wxGetApp function which returns
- a reference to the application object. Otherwise you can only use the global
+ Note the use of IMPLEMENT_APP(appClass), which allows wxWidgets to dynamically create
+ an instance of the application object at the appropriate point in wxWidgets initialization.
+ Previous versions of wxWidgets used to rely on the creation of a global application object,
+ but this is no longer recommended, because required global initialization may not have
+ been performed at application object construction time.
+
+ You can also use DECLARE_APP(appClass) in a header file to declare the wxGetApp function
+ which returns a reference to the application object. Otherwise you can only use the global
@c wxTheApp pointer which is of type @c wxApp *.
- @ref appshutdown_overview
- @section wxappshutdownoverview Application shutdown
+ @section overview_app_shutdown Application shutdown
The application normally shuts down when the last of its top level windows is
closed. This is normally the expected behaviour and means that it is enough to
- call #Close() in response to the @c "Exit" menu
- command if your program has a single top level window. If this behaviour is not
- desirable wxApp::SetExitOnFrameDelete can
- be called to change it. Note that starting from wxWidgets 2.3.3 such logic
- doesn't apply for the windows shown before the program enters the main loop: in
- other words, you can safely show a dialog from
- wxApp::OnInit and not be afraid that your application
- terminates when this dialog -- which is the last top level window for the
- moment -- is closed.
+ call #Close() in response to the @c "Exit" menu command if your program has a single
+ top level window. If this behaviour is not desirable wxApp::SetExitOnFrameDelete can
+ be called to change it.
+
+ Note that starting from wxWidgets 2.3.3 such logic doesn't apply for the windows shown
+ before the program enters the main loop: in other words, you can safely show a dialog from
+ wxApp::OnInit and not be afraid that your application terminates when this dialog --
+ which is the last top level window for the moment -- is closed.
Another aspect of the application shutdown is #OnExit
which is called when the application exits but @e before wxWidgets cleans up
its internal structures. You should delete all wxWidgets object that you
- created by the time OnExit finishes. In particular, do @b not destroy them
- from application class' destructor!
+ created by the time OnExit finishes.
+
+ In particular, do @b not destroy them from application class' destructor!
For example, this code may crash:
@code
}
@endcode
- */
-
+*/
/////////////////////////////////////////////////////////////////////////////
-// Name: arc
+// Name: arc.h
// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
/*!
- @page arc_overview Archive formats such as zip
+ @page overview_arc Archive formats such as zip
The archive classes handle archive formats such as zip, tar, rar and cab.
- Currently #wxZip
- and #wxTar classes are included.
+ Currently #wxZip and #wxTar classes are included.
+
For each archive type, there are the following classes (using zip here
as an example):
-
-
-
-
-
- #wxZipInputStream
-
-
-
-
- Input stream
-
-
-
-
-
- #wxZipOutputStream
-
-
-
-
- Output stream
-
-
-
-
-
- #wxZipEntry
-
-
-
-
- Holds the meta-data for an
- entry (e.g. filename, timestamp, etc.)
-
-
-
-
+ @li wxZipInputStream: input stream
+ @li wxZipOutputStream: output stream
+ @li wxZipEntry: holds the meta-data for an entry (e.g. filename, timestamp, etc.)
There are also abstract wxArchive classes that can be used to write code
- that can handle any of the archive types,
- see '@ref arcgeneric_overview'.
+ that can handle any of the archive types, see @ref overview_arc_generic.
+
Also see #wxFileSystem for a higher level interface that
can handle archive files in a generic way.
+
The classes are designed to handle archives on both seekable streams such
as disk files, or non-seekable streams such as pipes and sockets
- (see '@ref arcnoseek_overview').
- @b See also
- #wxFileSystem
+ (see @ref overview_arc_noseek).
+
+ See also #wxFileSystem.
- @ref arccreate_overview
- @ref arcextract_overview
- @ref arcmodify_overview
- @ref arcbyname_overview
- @ref arcgeneric_overview
- @ref arcnoseek_overview
+ @li @ref overview_arc_create
+ @li @ref overview_arc_extract
+ @li @ref overview_arc_modify
+ @li @ref overview_arc_byname
+ @li @ref overview_arc_generic
+ @li @ref overview_arc_noseek
- @section wxarccreate Creating an archive
+ <hr>
- @ref arc_overview
- Call #PutNextEntry() to
- create each new entry in the archive, then write the entry's data.
+
+ @section overview_arc_create Creating an archive
+
+ Call #PutNextEntry() to create each new entry in the archive, then write the entry's data.
Another call to PutNextEntry() closes the current entry and begins the next.
For example:
@code
- wxFFileOutputStream out(_T("test.zip"));
+ wxFFileOutputStream out(_T("test.zip"));
wxZipOutputStream zip(out);
wxTextOutputStream txt(zip);
wxString sep(wxFileName::GetPathSeparator());
store entries in subdirectories.
- @section wxarcextract Extracting an archive
+ @section overview_arc_extract Extracting an archive
+
+ #GetNextEntry() returns a pointer to entry object containing the meta-data for
+ the next entry in the archive (and gives away ownership).
+
+ Reading from the input stream then returns the entry's data.
+ Eof() becomes @true after an attempt has been made to read past the end of the entry's data.
- @ref arc_overview
- #GetNextEntry() returns a pointer
- to entry object containing the meta-data for the next entry in the archive
- (and gives away ownership). Reading from the input stream then returns the
- entry's data. Eof() becomes @true after an attempt has been made to read past
- the end of the entry's data.
When there are no more entries, GetNextEntry() returns @NULL and sets Eof().
@code
- auto_ptrwxZipEntry entry;
+ auto_ptr<wxZipEntry> entry;
wxFFileInputStream in(_T("test.zip"));
wxZipInputStream zip(in);
- @section wxarcmodify Modifying an archive
+ @section overview_arc_modify Modifying an archive
- @ref arc_overview
To modify an existing archive, write a new copy of the archive to a new file,
making any necessary changes along the way and transferring any unchanged
entries using #CopyEntry().
+
For archive types which compress entry data, CopyEntry() is likely to be
much more efficient than transferring the data using Read() and Write()
since it will copy them without decompressing and recompressing them.
+
In general modifications are not possible without rewriting the archive,
though it may be possible in some limited cases. Even then, rewriting the
archive is usually a better choice since a failure can be handled without
- losing the whole
- archive. #wxTempFileOutputStream can
- be helpful to do this.
+ losing the whole archive. #wxTempFileOutputStream can be helpful to do this.
+
For example to delete all entries matching the pattern "*.txt":
@code
- auto_ptrwxFFileInputStream in(new wxFFileInputStream(_T("test.zip")));
+ auto_ptr<wxFFileInputStream> in(new wxFFileInputStream(_T("test.zip")));
wxTempFileOutputStream out(_T("test.zip"));
wxZipInputStream inzip(*in);
wxZipOutputStream outzip(out);
- auto_ptrwxZipEntry entry;
+ auto_ptr<wxZipEntry> entry;
// transfer any meta-data for the archive as a whole (the zip comment
// in the case of zip)
- @section wxarcbyname Looking up an archive entry by name
+ @section overview_arc_byname Looking up an archive entry by name
- @ref arc_overview
Also see #wxFileSystem for a higher level interface that is
more convenient for accessing archive entries by name.
+
To open just one entry in an archive, the most efficient way is
- to simply search for it linearly by calling
- #GetNextEntry() until the
+ to simply search for it linearly by calling #GetNextEntry() until the
required entry is found. This works both for archives on seekable and
non-seekable streams.
+
The format of filenames in the archive is likely to be different
from the local filename format. For example zips and tars use
unix style names, with forward slashes as the path separator,
and absolute paths are not allowed. So if on Windows the file
- "C:\MYDIR\MYFILE.TXT" is stored, then when reading
- the entry back #GetName() will return
- "MYDIR\MYFILE.TXT". The conversion into the internal format
+ "C:\MYDIR\MYFILE.TXT" is stored, then when reading the entry back #GetName()
+ will return "MYDIR\MYFILE.TXT". The conversion into the internal format
and back has lost some information.
+
So to avoid ambiguity when searching for an entry matching a local name,
it is better to convert the local name to the archive's internal format
and search for that:
@code
- auto_ptrwxZipEntry entry;
+ auto_ptr<wxZipEntry> entry;
// convert the local name we are looking for into the internal format
wxString name = wxZipEntry::GetInternalName(localname);
To access several entries randomly, it is most efficient to transfer the
entire catalogue of entries to a container such as a std::map or a
- #wxHashMap then entries looked up by name can be
- opened using the #OpenEntry() method.
+ #wxHashMap then entries looked up by name can be opened using the #OpenEntry() method.
@code
- WX_DECLARE_STRING_HASH_MAP(wxZipEntry*, ZipCatalog);
+ WX_DECLARE_STRING_HASH_MAP(wxZipEntry*, ZipCatalog);
ZipCatalog::iterator it;
wxZipEntry *entry;
ZipCatalog cat;
underlying stream on the same archive:
@code
- // opening another entry without closing the first requires another
+ // opening another entry without closing the first requires another
// input stream for the same file
wxFFileInputStream in2(_T("test.zip"));
wxZipInputStream zip2(in2);
- @section wxarcgeneric Generic archive programming
+ @section overview_arc_generic Generic archive programming
- @ref arc_overview
Also see #wxFileSystem for a higher level interface that
can handle archive files in a generic way.
+
The specific archive classes, such as the wxZip classes, inherit from
the following abstract classes which can be used to write code that can
handle any of the archive types:
-
-
-
-
-
- #wxArchiveInputStream
-
-
-
-
- Input stream
-
-
-
-
-
- #wxArchiveOutputStream
-
-
-
-
- Output stream
-
-
-
-
-
- #wxArchiveEntry
-
-
-
-
- Holds the meta-data for an
- entry (e.g. filename)
-
-
-
-
+ @li wxArchiveInputStream: input stream
+ @li wxArchiveOutputStream: output stream
+ @li wxArchiveEntry: holds the meta-data for an entry (e.g. filename)
In order to able to write generic code it's necessary to be able to create
instances of the classes without knowing which archive type is being used.
+
To allow this there is a class factory for each archive type, derived from
- #wxArchiveClassFactory, that can create
- the other classes.
+ #wxArchiveClassFactory, that can create the other classes.
+
For example, given @e wxArchiveClassFactory* factory, streams and
entries can be created like this:
@code
- // create streams without knowing their type
- auto_ptrwxArchiveInputStream inarc(factory-NewStream(in));
- auto_ptrwxArchiveOutputStream outarc(factory-NewStream(out));
+ // create streams without knowing their type
+ auto_ptr<wxArchiveInputStream> inarc(factory-NewStream(in));
+ auto_ptr<wxArchiveOutputStream> outarc(factory-NewStream(out));
// create an empty entry object
- auto_ptrwxArchiveEntry entry(factory-NewEntry());
+ auto_ptr<wxArchiveEntry> entry(factory-NewEntry());
@endcode
- For the factory itself, the static member
- wxArchiveClassFactory::Find().
+ For the factory itself, the static member wxArchiveClassFactory::Find().
can be used to find a class factory that can handle a given file
extension or mime type. For example, given @e filename:
@code
- const wxArchiveClassFactory *factory;
+ const wxArchiveClassFactory *factory;
factory = wxArchiveClassFactory::Find(filename, wxSTREAM_FILEEXT);
if (factory)
@e Find does not give away ownership of the returned pointer, so it
does not need to be deleted.
+
There are similar class factories for the filter streams that handle the
compression and decompression of a single stream, such as wxGzipInputStream.
- These can be found using
- wxFilterClassFactory::Find().
+ These can be found using wxFilterClassFactory::Find().
+
For example, to list the contents of archive @e filename:
@code
- auto_ptrwxInputStream in(new wxFFileInputStream(filename));
+ auto_ptr<wxInputStream> in(new wxFFileInputStream(filename));
if (in-IsOk())
{
const wxArchiveClassFactory *acf;
acf = wxArchiveClassFactory::Find(filename, wxSTREAM_FILEEXT);
if (acf) {
- auto_ptrwxArchiveInputStream arc(acf-NewStream(in.release()));
- auto_ptrwxArchiveEntry entry;
+ auto_ptr<wxArchiveInputStream> arc(acf-NewStream(in.release()));
+ auto_ptr<wxArchiveEntry> entry;
// list the contents of the archive
while ((entry.reset(arc-GetNextEntry())), entry.get() != @NULL)
- @section wxarcnoseek Archives on non-seekable streams
+ @section overview_arc_noseek Archives on non-seekable streams
- @ref arc_overview
In general, handling archives on non-seekable streams is done in the same
way as for seekable streams, with a few caveats.
- The main limitation is that accessing entries randomly using
- #OpenEntry()
+
+ The main limitation is that accessing entries randomly using #OpenEntry()
is not possible, the entries can only be accessed sequentially in the order
they are stored within the archive.
+
For each archive type, there will also be other limitations which will
depend on the order the entries' meta-data is stored within the archive.
These are not too difficult to deal with, and are outlined below.
+
@b PutNextEntry and the entry size
When writing archives, some archive formats store the entry size before
the entry's data (tar has this limitation, zip doesn't). In this case
- the entry's size must be passed to
- #PutNextEntry() or an error
- occurs.
+ the entry's size must be passed to #PutNextEntry() or an error occurs.
+
This is only an issue on non-seekable streams, since otherwise the archive
output stream can seek back and fix up the header once the size of the
entry is known.
+
For generic programming, one way to handle this is to supply the size
whenever it is known, and rely on the error message from the output
stream when the operation is not supported.
+
@b GetNextEntry and the weak reference mechanism
Some archive formats do not store all an entry's meta-data before the
entry's data (zip is an example). In this case, when reading from a
- non-seekable stream, #GetNextEntry()
- can only return a partially populated #wxArchiveEntry
- object - not all the fields are set.
+ non-seekable stream, #GetNextEntry() can only return a partially populated
+ #wxArchiveEntry object - not all the fields are set.
+
The input stream then keeps a weak reference to the entry object and
updates it when more meta-data becomes available. A weak reference being
one that does not prevent you from deleting the wxArchiveEntry object - the
input stream only attempts to update it if it is still around.
+
The documentation for each archive entry type gives the details
of what meta-data becomes available and when. For generic programming,
when the worst case must be assumed, you can rely on all the fields
of wxArchiveEntry being fully populated when GetNextEntry() returns,
with the the following exceptions:
+ @li GetSize(): Guaranteed to be available after the entry has been read to #Eof(),
+ or #CloseEntry() has been called
+ @li IsReadOnly(): Guaranteed to be available after the end of the archive has been
+ reached, i.e. after GetNextEntry() returns @NULL and Eof() is @true
+ This mechanism allows #CopyEntry() to always fully preserve entries' meta-data.
+ No matter what order order the meta-data occurs within the archive, the input stream
+ will always have read it before the output stream must write it.
-
-
- #GetSize()
-
-
-
-
- Guaranteed to be
- available after the entry has been read to #Eof(),
- or #CloseEntry() has been called
-
-
-
-
-
- #IsReadOnly()
-
-
-
-
- Guaranteed to
- be available after the end of the archive has been reached, i.e. after
- GetNextEntry() returns @NULL and Eof() is @true
-
-
-
-
-
- This mechanism allows #CopyEntry()
- to always fully preserve entries' meta-data. No matter what order order
- the meta-data occurs within the archive, the input stream will always
- have read it before the output stream must write it.
@b wxArchiveNotifier
Notifier objects can be used to get a notification whenever an input
stream updates a #wxArchiveEntry object's data
via the weak reference mechanism.
+
Consider the following code which renames an entry in an archive.
This is the usual way to modify an entry's meta-data, simply set the
- required field before writing it with
- #CopyEntry():
+ required field before writing it with #CopyEntry():
@code
- auto_ptrwxArchiveInputStream arc(factory-NewStream(in));
- auto_ptrwxArchiveOutputStream outarc(factory-NewStream(out));
- auto_ptrwxArchiveEntry entry;
+ auto_ptr<wxArchiveInputStream> arc(factory-NewStream(in));
+ auto_ptr<wxArchiveOutputStream> outarc(factory-NewStream(out));
+ auto_ptr<wxArchiveEntry> entry;
outarc-CopyArchiveMetaData(*arc);
@endcode
However, for non-seekable streams, this technique cannot be used for
- fields such as #IsReadOnly(),
- which are not necessarily set when
- #GetNextEntry() returns. In
- this case a #wxArchiveNotifier can be used:
+ fields such as #IsReadOnly(), which are not necessarily set when
+ #GetNextEntry() returns. In this case a #wxArchiveNotifier can be used:
@code
class MyNotifier : public wxArchiveNotifier
};
@endcode
- The meta-data changes are done in your notifier's
- #OnEntryUpdated() method,
- then #SetNotifier() is called before
- CopyEntry():
+ The meta-data changes are done in your notifier's #OnEntryUpdated() method,
+ then #SetNotifier() is called before CopyEntry():
@code
- auto_ptrwxArchiveInputStream arc(factory-NewStream(in));
- auto_ptrwxArchiveOutputStream outarc(factory-NewStream(out));
- auto_ptrwxArchiveEntry entry;
+ auto_ptr<wxArchiveInputStream> arc(factory-NewStream(in));
+ auto_ptr<wxArchiveOutputStream> outarc(factory-NewStream(out));
+ auto_ptr<wxArchiveEntry> entry;
MyNotifier notifier;
outarc-CopyArchiveMetaData(*arc);
changing the entry name can be done this way too and it works on seekable
streams as well as non-seekable.
- */
-
+*/
/////////////////////////////////////////////////////////////////////////////
-// Name: aui
+// Name: aui.h
// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
/*!
- @page aui_overview wxAUI overview
+ @page overview_aui wxAUI overview
Class: #wxAuiManager, #wxAuiPaneInfo
+
wxAUI stands for Advanced User Interface and the wxAUI framework
aims to give its user a cutting edge interface for use with the
wxWidgets based applications. The original wxAUI sources have
kindly been made available under the wxWindows licence
by Kirix Corp. and they have since then been integrated into
wxWidgets CVS and further improved.
+
wxAUI attempts to encapsulate the following aspects of the user interface:
+
@b Frame Management:
Frame management provides the means to open, move and hide common
controls that are needed to interact with the document, and allow these
configurations to be saved into different perspectives and loaded at a
later time.
+
@b Toolbars:
Toolbars are a specialized subset of the frame management system and
should behave similarly to other docked components. However, they also
require additional functionality, such as "spring-loaded" rebar support,
"chevron" buttons and end-user customizability.
+
@b Modeless Controls:
Modeless controls expose a tool palette or set of options that float
above the application content while allowing it to be accessed. Usually
accessed by the toolbar, these controls disappear when an option is
selected, but may also be "torn off" the toolbar into a floating frame
of their own.
+
@b Look and Feel:
Look and feel encompasses the way controls are drawn, both when shown
statically as well as when they are being moved. This aspect of user
interface design incorporates "special effects" such as transparent
window dragging as well as frame animation.
+
wxAUI adheres to the following principles:
Use native floating frames to obtain a native look and feel for all
platforms. Use existing wxWidgets code where possible, such as sizer
implementation for frame management. Use classes included in wxCore
and wxBase only. Use standard wxWidgets coding conventions.
- */
-
-
+*/
/////////////////////////////////////////////////////////////////////////////
-// Name: backwardcompatibility
+// Name: backwardcompatibility.h
// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
/*!
- @page backwardcompatibility_overview Backward compatibility
+ @page overview_backwardcompat Backward compatibility
Many of the GUIs and platforms supported by wxWidgets are continuously
evolving, and some of the new platforms wxWidgets now supports were quite
unimaginable even a few years ago. In this environment wxWidgets must also
evolve in order to support these new features and platforms.
+
However the goal of wxWidgets is not only to provide a consistent
programming interface across many platforms, but also to provide an
interface that is reasonably stable over time, to help protect its users
from some of the uncertainty of the future.
- @ref versionnumbering_overview
- @ref sourcecompatibility_overview
- @ref libbincompatibility_overview
- @ref appbincompatibility_overview
+ @li @ref overview_backwardcompat_versionnumbering
+ @li @ref overview_backwardcompat_sourcecompat
+ @li @ref overview_backwardcompat_libbincompat
+ @li @ref overview_backwardcompat_appbincompat
+
+
+ <hr>
- @section versionnumbering The version numbering scheme
+
+ @section overview_backwardcompat_versionnumbering The version numbering scheme
wxWidgets version numbers can have up to four components, with trailing
zeros sometimes omitted:
changes are permitted, but only those that are backward compatible. For
example, you can expect later @c 2.6.x.x releases, such as @c 2.6.1
and @c 2.6.2 to be backward compatible with their predecessor.
+
When it becomes necessary to make changes which are not wholly backward
compatible, the stable branch is forked, creating a new development
branch of wxWidgets. This development branch will have an odd number
for @c minor, for example @c 2.7.x.x. Releases from this branch are
known as development snapshots.
+
The stable branch and the development branch will then be developed in
parallel for some time. When it is no longer useful to continue developing
the stable branch, the development branch is renamed and becomes a new
stable branch, for example @c 2.8.0. And the process begins again.
This is how the tension between keeping the interface stable, and allowing
the library to evolve is managed.
+
You can expect the versions with the same major and even minor
version number to be compatible, but between minor versions there will be
incompatibilities. Compatibility is not broken gratuitously however, so
many applications will require no changes or only small changes to work
with the new version.
- @section sourcecompatibility Source level compatibility
+
+ @section overview_backwardcompat_sourcecompat Source level compatibility
Later releases from a stable branch are backward compatible with earlier
releases from the same branch at the source level.
This means that, for example, if you develop your application using
- wxWidgets @c 2.6.0 then it should also compile fine with all later @c 2.6.x versions. The converse is also @true providing you avoid any new
+ wxWidgets @c 2.6.0 then it should also compile fine with all later @c 2.6.x versions.
+
+ The converse is also @true providing you avoid any new
features not present in the earlier version. For example if you develop
using @c 2.6.1 your program will compile fine with wxWidgets @c 2.6.0
providing you don't use any @c 2.6.1 specific features.
+
For some platforms binary compatibility is also supported, see 'Library
binary compatibility' below.
- Between minor versions, for example between @c 2.2.x, @c 2.4.x and @c 2.6.x, there will be some incompatibilities. Wherever possible the old way
- of doing something is kept alongside the new for a time wrapped inside:
+
+ Between minor versions, for example between @c 2.2.x, @c 2.4.x and @c 2.6.x, there
+ will be some incompatibilities. Wherever possible the old way of doing something
+ is kept alongside the new for a time wrapped inside:
@code
#if WXWIN_COMPATIBILITY_2_4
- /* deprecated feature */
-...
-#endif
-@endcode
-
-By default the @c WXWIN_COMPATIBILITY@e _X_X macro is set
- to 1 for the previous stable branch, for example
- in @c 2.6.x @c WXWIN_COMPATIBILITY_2_4 = 1. For the next earlier
- stable branch the default is 0, so @c WXWIN_COMPATIBILITY_2_2 = 0
- for @c 2.6.x. Earlier than that, obsolete features are removed.
- These macros can be changed in @c setup.h. Or on UNIX-like systems you can
- set them using the @c --disable-compat24 and @c --enable-compat22
- options to @c configure.
- They can be useful in two ways:
-
-
-Changing @c WXWIN_COMPATIBILITY_2_4 to 0 can be useful to
-find uses of deprecated features in your program.
-Changing @c WXWIN_COMPATIBILITY_2_2 to 1 can be useful to
-compile a program developed using @c 2.2.x that no longer compiles
-with @c 2.6.x.
-
-
-A program requiring one of these macros to be 1 will become
-incompatible with some future version of wxWidgets, and you should consider
-updating it.
-
-@section libbincompatibility Library binary compatibility
-
-For some platforms, releases from a stable branch are not only source level
-compatible but can also be binary compatible.
-Binary compatibility makes it possible to get the maximum benefit from
-using shared libraries, also known as dynamic link libraries (DLLs) on
-Windows or dynamic shared libraries on OS X.
-For example, suppose several applications are installed on a system requiring
-wxWidgets @c 2.6.0, @c 2.6.1 and @c 2.6.2. Since @c 2.6.2 is
-backward compatible with the earlier versions, it should be enough to
-install just wxWidgets @c 2.6.2 shared libraries, and all the applications
-should be able to use them. If binary compatibility is not supported, then all
-the required versions @c 2.6.0, @c 2.6.1 and @c 2.6.2 must be
-installed side by side.
-Achieving this, without the user being required to have the source code
-and recompile everything, places many extra constraints on the changes
-that can be made within the stable branch. So it is not supported for all
-platforms, and not for all versions of wxWidgets. To date it has mainly
- been supported by wxGTK for UNIX-like platforms.
- Another practical consideration is that for binary compatibility to work,
- all the applications and libraries must have been compiled with compilers
- that are capable of producing compatible code;
-that is, they must use the
-same ABI (Application Binary Interface). Unfortunately most different C++
-compilers do not produce code compatible with each other, and often even
- different versions of the same compiler are not compatible.
-
- @section appbincompatibility Application binary compatibility
-
- The most important aspect of binary compatibility is that applications
- compiled with one version of wxWidgets, e.g. @c 2.6.1, continue to work
- with shared libraries of a later binary compatible version, for example @c 2.6.2.
- The converse can also be useful however. That is, it can be useful for a
- developer using a later version, e.g. @c 2.6.2 to be able to create binary
- application packages that will work with all binary compatible versions of
- the shared library starting with, for example @c 2.6.0.
- To do this the developer must, of course, avoid any features not available
- in the earlier versions. However this is not necessarily enough;
-in some
-cases an application compiled with a later version may depend on it even
-though the same code would compile fine against an earlier version.
-To help with this, a preprocessor symbol @c wxABI_VERSION can be defined
-during the compilation of the application (this would usually be done in the
- application's makefile or project settings). It should be set to the lowest
- version that is being targeted, as a number with two decimal digits for each
- component, for example @c wxABI_VERSION=20600 for @c 2.6.0.
- Setting @c wxABI_VERSION should prevent the application from implicitly
- depending on a later version of wxWidgets, and also disables any new features
- in the API, giving a compile time check that the source is compatible with
- the versions of wxWidgets being targeted.
- Uses of @c wxABI_VERSION are stripped out of the wxWidgets sources when
- each new development branch is created. Therefore it is only useful to help
- achieve compatibility with earlier versions with the same major
- and even minor version numbers. It won't, for example, help you write
- code compatible with @c 2.4.x using wxWidgets @c 2.6.x.
-
- */
+ // deprecated feature
+ ...
+ #endif
+ @endcode
+ By default the @c WXWIN_COMPATIBILITY@e _X_X macro is set
+ to 1 for the previous stable branch, for example
+ in @c 2.6.x @c WXWIN_COMPATIBILITY_2_4 = 1. For the next earlier
+ stable branch the default is 0, so @c WXWIN_COMPATIBILITY_2_2 = 0
+ for @c 2.6.x. Earlier than that, obsolete features are removed.
+
+ These macros can be changed in @c setup.h. Or on UNIX-like systems you can
+ set them using the @c --disable-compat24 and @c --enable-compat22
+ options to @c configure.
+
+ They can be useful in two ways:
+
+ @li changing @c WXWIN_COMPATIBILITY_2_4 to 0 can be useful to
+ find uses of deprecated features in your program.
+ @li changing @c WXWIN_COMPATIBILITY_2_2 to 1 can be useful to
+ compile a program developed using @c 2.2.x that no longer compiles
+ with @c 2.6.x.
+
+ A program requiring one of these macros to be 1 will become
+ incompatible with some future version of wxWidgets, and you should consider
+ updating it.
+
+
+
+ @section overview_backwardcompat_libbincompat Library binary compatibility
+
+ For some platforms, releases from a stable branch are not only source level
+ compatible but can also be binary compatible.
+
+ Binary compatibility makes it possible to get the maximum benefit from
+ using shared libraries, also known as dynamic link libraries (DLLs) on
+ Windows or dynamic shared libraries on OS X.
+
+ For example, suppose several applications are installed on a system requiring
+ wxWidgets @c 2.6.0, @c 2.6.1 and @c 2.6.2. Since @c 2.6.2 is
+ backward compatible with the earlier versions, it should be enough to
+ install just wxWidgets @c 2.6.2 shared libraries, and all the applications
+ should be able to use them. If binary compatibility is not supported, then all
+ the required versions @c 2.6.0, @c 2.6.1 and @c 2.6.2 must be
+ installed side by side.
+
+ Achieving this, without the user being required to have the source code
+ and recompile everything, places many extra constraints on the changes
+ that can be made within the stable branch. So it is not supported for all
+ platforms, and not for all versions of wxWidgets. To date it has mainly
+ been supported by wxGTK for UNIX-like platforms.
+
+ Another practical consideration is that for binary compatibility to work,
+ all the applications and libraries must have been compiled with compilers
+ that are capable of producing compatible code;
+ that is, they must use the
+ same ABI (Application Binary Interface). Unfortunately most different C++
+ compilers do not produce code compatible with each other, and often even
+ different versions of the same compiler are not compatible.
+
+
+
+ @section overview_backwardcompat_appbincompat Application binary compatibility
+
+ The most important aspect of binary compatibility is that applications
+ compiled with one version of wxWidgets, e.g. @c 2.6.1, continue to work
+ with shared libraries of a later binary compatible version, for example @c 2.6.2.
+ The converse can also be useful however. That is, it can be useful for a
+ developer using a later version, e.g. @c 2.6.2 to be able to create binary
+ application packages that will work with all binary compatible versions of
+ the shared library starting with, for example @c 2.6.0.
+
+ To do this the developer must, of course, avoid any features not available
+ in the earlier versions. However this is not necessarily enough;
+ in some cases an application compiled with a later version may depend on it even
+ though the same code would compile fine against an earlier version.
+
+ To help with this, a preprocessor symbol @c wxABI_VERSION can be defined
+ during the compilation of the application (this would usually be done in the
+ application's makefile or project settings). It should be set to the lowest
+ version that is being targeted, as a number with two decimal digits for each
+ component, for example @c wxABI_VERSION=20600 for @c 2.6.0.
+
+ Setting @c wxABI_VERSION should prevent the application from implicitly
+ depending on a later version of wxWidgets, and also disables any new features
+ in the API, giving a compile time check that the source is compatible with
+ the versions of wxWidgets being targeted.
+
+ Uses of @c wxABI_VERSION are stripped out of the wxWidgets sources when
+ each new development branch is created. Therefore it is only useful to help
+ achieve compatibility with earlier versions with the same major
+ and even minor version numbers. It won't, for example, help you write
+ code compatible with @c 2.4.x using wxWidgets @c 2.6.x.
+
+*/
/////////////////////////////////////////////////////////////////////////////
-// Name: bitmap
+// Name: bitmap.h
// Purpose: topic overview
// Author: wxWidgets team
// RCS-ID: $Id$
@b Note: bitmap handlers are not implemented on all platforms, and new ones rarely need
to be implemented since wxImage can be used for loading most formats, as noted earlier.
- */
-
+*/
projects / wxWidgets.git / commitdiff
