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 @code
#if WXWIN_COMPATIBILITY_2_4 #if WXWIN_COMPATIBILITY_2_4
/* deprecated feature */ /* deprecated feature */
... ...
#endif #endif
@endcode @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 to 1 for the previous stable branch, for example
in @c 2.6.x @c WXWIN_COMPATIBILITY_2_4 = 1. For the next earlier 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 stable branch the default is 0, so @c WXWIN_COMPATIBILITY_2_2 = 0
@@ -87,41 +87,42 @@
They can be useful in two ways: They can be useful in two ways:
Changing @c WXWIN_COMPATIBILITY_2_4 to 0 can be useful to Changing @c WXWIN_COMPATIBILITY_2_4 to 0 can be useful to
find uses of deprecated features in your program. find uses of deprecated features in your program.
Changing @c WXWIN_COMPATIBILITY_2_2 to 1 can be useful to 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 compile a program developed using @c 2.2.x that no longer compiles
with @c 2.6.x. with @c 2.6.x.
A program requiring one of these macros to be 1 will become A program requiring one of these macros to be 1 will become
incompatible with some future version of wxWidgets, and you should consider incompatible with some future version of wxWidgets, and you should consider
updating it. 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 For some platforms, releases from a stable branch are not only source level
compatible but can also be binary compatible. compatible but can also be binary compatible.
Binary compatibility makes it possible to get the maximum benefit from Binary compatibility makes it possible to get the maximum benefit from
using shared libraries, also known as dynamic link libraries (DLLs) on using shared libraries, also known as dynamic link libraries (DLLs) on
Windows or dynamic shared libraries on OS X. Windows or dynamic shared libraries on OS X.
For example, suppose several applications are installed on a system requiring 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 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 backward compatible with the earlier versions, it should be enough to
install just wxWidgets @c 2.6.2 shared libraries, and all the applications 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 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 the required versions @c 2.6.0, @c 2.6.1 and @c 2.6.2 must be
installed side by side. installed side by side.
Achieving this, without the user being required to have the source code Achieving this, without the user being required to have the source code
and recompile everything, places many extra constraints on the changes 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 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 platforms, and not for all versions of wxWidgets. To date it has mainly
been supported by wxGTK for UNIX-like platforms. been supported by wxGTK for UNIX-like platforms.
Another practical consideration is that for binary compatibility to work, Another practical consideration is that for binary compatibility to work,
all the applications and libraries must have been compiled with compilers all the applications and libraries must have been compiled with compilers
that are capable of producing compatible code; that is, they must use the that are capable of producing compatible code;
same ABI (Application Binary Interface). Unfortunately most different C++ that is, they must use the
compilers do not produce code compatible with each other, and often even 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. different versions of the same compiler are not compatible.
@section appbincompatibility Application binary compatibility @section appbincompatibility Application binary compatibility
@@ -134,11 +135,12 @@
application packages that will work with all binary compatible versions of application packages that will work with all binary compatible versions of
the shared library starting with, for example @c 2.6.0. the shared library starting with, for example @c 2.6.0.
To do this the developer must, of course, avoid any features not available 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 in the earlier versions. However this is not necessarily enough;
cases an application compiled with a later version may depend on it even in some
though the same code would compile fine against an earlier version. cases an application compiled with a later version may depend on it even
To help with this, a preprocessor symbol @c wxABI_VERSION can be defined though the same code would compile fine against an earlier version.
during the compilation of the application (this would usually be done in the 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 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 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. 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) switch (result)
{ {
case wxDragCopy: /* copy the data */ break; case wxDragCopy: /* copy the data */ break;
case wxDragMove: /* move the data */ break; case wxDragMove: /* move the data */
default: /* do nothing */ break; break;
} default: /* do nothing */
@endcode break;
}
@endcode
To be a @e drop target, i.e. to receive the data dropped by the user you should To be a @e drop target, i.e. to receive the data dropped by the user you should
follow the instructions below: follow the instructions below:
@b Initialization: For a window to be a drop target, it needs to have @b Initialization: For a window to be a drop target, it needs to have
an associated #wxDropTarget object. Normally, you will an associated #wxDropTarget object. Normally, you will
call wxWindow::SetDropTarget during window call wxWindow::SetDropTarget during window
creation associating your drop target with it. You must derive a class from creation associating your drop target with it. You must derive a class from
wxDropTarget and override its pure virtual methods. Alternatively, you may wxDropTarget and override its pure virtual methods. Alternatively, you may
derive from #wxTextDropTarget or derive from #wxTextDropTarget or
#wxFileDropTarget and override their OnDropText() #wxFileDropTarget and override their OnDropText()
or OnDropFiles() method. or OnDropFiles() method.
@b Drop: When the user releases the mouse over a window, wxWidgets @b Drop: When the user releases the mouse over a window, wxWidgets
asks the associated wxDropTarget object if it accepts the data. For this, 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, #wxLogNull,
#wxLogBuffer,
#wxLogChain, #wxLogChain,
#wxLogInterposer, #wxLogInterposer,
@@ -155,6 +157,8 @@
collects all messages generated by the application and also passes them to the 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 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. 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 @b wxLogNull The last log class is quite particular: it doesn't do
anything. The objects of this class may be instantiated to (temporarily) anything. The objects of this class may be instantiated to (temporarily)
suppress output of @e wxLogXXX() functions. As an example, trying to open a suppress output of @e wxLogXXX() functions. As an example, trying to open a