Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions 8 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

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

@@ -72,86 +72,88 @@
@code
#if WXWIN_COMPATIBILITY_2_4
/* deprecated feature */
...
#endif
@endcode
...
#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:
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.
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
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.
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
@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.
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.
*/
*/

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

@@ -42,8 +42,8 @@
@code
wxDropSource dragSource( this );
dragSource.SetData( my_data );
wxDragResult result = dragSource.DoDragDrop( TRUE );
dragSource.SetData( my_data );
wxDragResult result = dragSource.DoDragDrop( TRUE );
@endcode
@b Dragging: The call to DoDragDrop() blocks the program until the user releases the
@@ -57,39 +57,41 @@
@code
switch (result)
{
case wxDragCopy: /* copy the data */ break;
case wxDragMove: /* move the data */ break;
default: /* do nothing */ break;
}
@endcode
{
case wxDragCopy: /* copy the data */ break;
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
wxDropTarget and override its pure virtual methods. Alternatively, you may
derive from #wxTextDropTarget or
#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,
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 #OnData
will get called and the wxDataObject belonging to the drop target can get
filled with data.
@b The end: After processing the data, DoDragDrop() returns either
wxDragCopy or wxDragMove depending on the state of the keys Ctrl, Shift
and Alt at the moment of the drop. There is currently no way for the drop
target to change this return code.
@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()
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,
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 #OnData
will get called and the wxDataObject belonging to the drop target can get
filled with data.
@b The end: After processing the data, DoDragDrop() returns either
wxDragCopy or wxDragMove depending on the state of the keys Ctrl, Shift
and Alt at the moment of the drop. There is currently no way for the drop
target to change this return code.
*/
*/

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

@@ -312,7 +312,7 @@
TAG_HANDLER_BEGIN(VARS_ONLY, "CRAZYTAG")
TAG_HANDLER_VARS
int my_int_var;
wxString something_else;
wxString something_else;
TAG_HANDLER_END(VARS_ONLY)
@endcode
@@ -328,8 +328,8 @@
int my_int_var;
TAG_HANDLER_CONSTR(vars2)
{ // !!!!!!
my_int_var = 666;
} // !!!!!!
my_int_var = 666;
} // !!!!!!
TAG_HANDLER_END(VARS2)
@endcode
@@ -344,8 +344,8 @@
TAG_HANDLER_BEGIN(TITLE, "TITLE")
TAG_HANDLER_PROC(tag)
{
printf("TITLE found...\n");
}
printf("TITLE found...\n");
}
TAG_HANDLER_END(TITLE)
@endcode

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

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

@@ -91,7 +91,7 @@
// Created: 04/01/98
// RCS-ID: $Id: ttoolbar.tex 47878 2007-08-05 10:10:37Z JS $
// Copyright: (c) Julian Smart
// License: wxWindows license
// License: wxWindows license
/////////////////////////////////////////////////////////////////////////////
// For compilers that support precompilation, includes "wx/wx.h".

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

@@ -500,16 +500,16 @@
#include "resource.h"
class TestWnd : public TestWnd_Base {
public:
TestWnd(){
// A, B already initialised at this point
A-SetValue("Updated in TestWnd::TestWnd");
B-SetValue("Nice :)");
}
void OnBPressed(wxEvent& event){
Close();
}
DECLARE_EVENT_TABLE();
public:
TestWnd(){
// A, B already initialised at this point
A-SetValue("Updated in TestWnd::TestWnd");
B-SetValue("Nice :)");
}
void OnBPressed(wxEvent& event){
Close();
}
DECLARE_EVENT_TABLE();
};
BEGIN_EVENT_TABLE(TestWnd,TestWnd_Base)