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

removed useless spaces

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@51911 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Francesco Montorsi
2008-02-19 13:28:24 +00:00
parent 4411a6b6b5
commit 36c9828f70
71 changed files with 5417 additions and 5409 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
docs/doxygen/overviews/backwardcompatibility.h
View File

@@ -72,11 +72,11 @@
@code
#if WXWIN_COMPATIBILITY_2_4
/* deprecated feature */
...
#endif
@endcode
...
#endif
@endcode
By default the @c WXWIN_COMPATIBILITY@e _X_X macro is set
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
@@ -87,41 +87,42 @@
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.
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.
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
@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
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
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
@@ -134,11 +135,12 @@
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
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.

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

@@ -59,24 +59,26 @@
switch (result)
{
case wxDragCopy: /* copy the data */ break;
case wxDragMove: /* move the data */ break;
default: /* do nothing */ break;
}
@endcode
case wxDragMove: /* move the data */
break;
default: /* do nothing */
break;
}
@endcode
To be a @e drop target, i.e. to receive the data dropped by the user you should
follow the instructions below:
To be a @e drop target, i.e. to receive the data dropped by the user you should
follow the instructions below:
@b Initialization: For a window to be a drop target, it needs to have
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
@b Initialization: For a window to be a drop target, it needs to have
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()
#wxFileDropTarget and override their OnDropText()
or OnDropFiles() method.
@b Drop: When the user releases the mouse over a window, wxWidgets
asks the associated wxDropTarget object if it accepts the data. For this,

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

@@ -24,6 +24,8 @@
#wxLogNull,
#wxLogBuffer,
#wxLogChain,
#wxLogInterposer,
@@ -155,6 +157,8 @@
collects all messages generated by the application and also passes them to the
previous active log target. The log window frame has a menu allowing user to
clear the log, close it completely or save all messages to file.
@b wxLogBuffer This target collects all the logged messages in an
internal buffer allowing to show them later to the user all at once.
@b wxLogNull The last log class is quite particular: it doesn't do
anything. The objects of this class may be instantiated to (temporarily)
suppress output of @e wxLogXXX() functions. As an example, trying to open a