Fixed various typos.
Applied patch by snowleopard2 fixing a bunch of typos such as misspellings and double words in the documentation. Combined the patch with some local queued typos waiting to be committed as well as adding new typo fixes inspired by the patch. Function names with American spelling were not changed nor was third-party code touched. The only code changes involve some changes in strings that are translated ("Can not" -> "Cannot"). Closes #13063 (again). git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67280 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -361,7 +361,7 @@ 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:
|
||||
fully populated when GetNextEntry() returns, with the following exceptions:
|
||||
|
||||
@li wxArchiveEntry::GetSize(): Guaranteed to be available after the entry has
|
||||
been read to wxInputStream::Eof(), or wxArchiveInputStream::CloseEntry()
|
||||
|
@@ -23,7 +23,7 @@ information. They were especially designed for this usage and, although may
|
||||
probably be used for many other things as well, should be limited to it. It
|
||||
means that this information should be:
|
||||
|
||||
@li Typed, i.e. strings or numbers for the moment. You can not store binary
|
||||
@li Typed, i.e. strings or numbers for the moment. You cannot store binary
|
||||
data, for example.
|
||||
@li Small. For instance, it is not recommended to use the Windows registry for
|
||||
amounts of data more than a couple of kilobytes.
|
||||
|
@@ -26,7 +26,7 @@ and is obviously easier and faster.
|
||||
However there are situations where you need to show some particular kind of data
|
||||
which is not suited to any existing control.
|
||||
In these cases rather than hacking an existing control for something it has not
|
||||
been coinceived for, it's better to write a new widget.
|
||||
been conceived for, it's better to write a new widget.
|
||||
|
||||
|
||||
@section overview_customwidgets_how How to write the custom widget
|
||||
|
@@ -794,7 +794,7 @@ wxTextCtrl, they navigate between adjacent properties. As such:
|
||||
@section propgrid_customizing Customizing Properties (without sub-classing)
|
||||
|
||||
In this section are presented miscellaneous ways to have custom appearance
|
||||
and behavior for your properties without all the necessary hassle
|
||||
and behaviour for your properties without all the necessary hassle
|
||||
of sub-classing a property class etc.
|
||||
|
||||
@subsection propgrid_customimage Setting Value Image
|
||||
@@ -957,7 +957,7 @@ wxPropertyGrid::CenterSplitter() method. <b>However, be sure to call it after
|
||||
the sizer setup and SetSize calls!</b> (ie. usually at the end of the
|
||||
frame/dialog constructor)
|
||||
|
||||
Splitter centering behavior can be customized using
|
||||
Splitter centering behaviour can be customized using
|
||||
wxPropertyGridInterface::SetColumnProportion(). Usually it is used to set
|
||||
non-equal column proportions, which in essence stops the splitter(s) from
|
||||
being 'centered' as such, and instead just auto-resized.
|
||||
@@ -994,7 +994,7 @@ Version of wxPropertyGrid bundled with wxWidgets 2.9+ has various backward-
|
||||
incompatible changes from version 1.4, which had a stable API and will remain
|
||||
as the last separate branch.
|
||||
|
||||
Note that in general any behavior-breaking changes should not compile or run
|
||||
Note that in general any behaviour-breaking changes should not compile or run
|
||||
without warnings or errors.
|
||||
|
||||
@subsection propgrid_compat_general General Changes
|
||||
@@ -1005,14 +1005,14 @@ without warnings or errors.
|
||||
with keyboard. This change allowed fixing broken tab traversal on wxGTK
|
||||
(which is open issue in wxPropertyGrid 1.4).
|
||||
|
||||
- wxPG_EX_UNFOCUS_ON_ENTER style is removed and is now default behavior.
|
||||
- wxPG_EX_UNFOCUS_ON_ENTER style is removed and is now default behaviour.
|
||||
That is, when enter is pressed, editing is considered done and focus
|
||||
moves back to the property grid from the editor control.
|
||||
|
||||
- A few member functions were removed from wxPropertyGridInterface.
|
||||
Please use wxPGProperty's counterparts from now on.
|
||||
|
||||
- wxPGChoices now has proper Copy-On-Write behavior.
|
||||
- wxPGChoices now has proper Copy-On-Write behaviour.
|
||||
|
||||
- wxPGChoices::SetExclusive() was renamed to AllocExclusive().
|
||||
|
||||
@@ -1026,15 +1026,15 @@ without warnings or errors.
|
||||
now use wxPropertyGridInterface::GetEditableState() instead.
|
||||
|
||||
- wxPG_EX_DISABLE_TLP_TRACKING is now enabled by default. To get the old
|
||||
behavior (recommended if you don't use a system that reparents the grid
|
||||
behaviour (recommended if you don't use a system that reparents the grid
|
||||
on its own), use the wxPG_EX_ENABLE_TLP_TRACKING extra style.
|
||||
|
||||
- Extended window style wxPG_EX_LEGACY_VALIDATORS was removed.
|
||||
|
||||
- Default property validation failure behavior has been changed to
|
||||
- Default property validation failure behaviour has been changed to
|
||||
(wxPG_VFB_MARK_CELL | wxPG_VFB_SHOW_MESSAGEBOX), which means that the
|
||||
cell is marked red and wxMessageBox is shown. This is more user-friendly
|
||||
than the old behavior, which simply beeped and prevented leaving the
|
||||
than the old behaviour, which simply beeped and prevented leaving the
|
||||
property editor until a valid value was entered.
|
||||
|
||||
- wxPropertyGridManager now has same Get/SetSelection() semantics as
|
||||
|
@@ -47,7 +47,7 @@ will return @true if two objects are identical and not only if they share the
|
||||
same data.
|
||||
|
||||
Note that wxWidgets follows the <em>STL philosophy</em>: when a comparison
|
||||
operator can not be implemented efficiently (like for e.g. wxImage's ==
|
||||
operator cannot be implemented efficiently (like for e.g. wxImage's ==
|
||||
operator which would need to compare the entire image's data, pixel-by-pixel),
|
||||
it's not implemented at all. That's why not all reference counted classes
|
||||
provide comparison operators.
|
||||
|
@@ -15,7 +15,7 @@ that descriptions of inherited member functions are not duplicated in derived
|
||||
classes unless their behaviour is different. So in using a class such as
|
||||
wxScrolledWindow, be aware that wxWindow functions may be relevant.
|
||||
|
||||
Where not explicitely stated, size and position arguments may usually be given a
|
||||
Where not explicitly stated, size and position arguments may usually be given a
|
||||
value of ::wxDefaultSize and ::wxDefaultPosition, in which case wxWidgets will
|
||||
choose suitable values.
|
||||
|
||||
|
@@ -7,7 +7,7 @@
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
/*
|
||||
NOTE: we explicitely don't name wxMutexGUIEnter() and wxMutexGUILeave()
|
||||
NOTE: we explicitly don't name wxMutexGUIEnter() and wxMutexGUILeave()
|
||||
as they're not safe. See also ticket #10366.
|
||||
*/
|
||||
|
||||
|
@@ -230,7 +230,7 @@ problems:
|
||||
- Using a cast to force the issue (listed only for completeness):
|
||||
@code printf("Hello, %s", (const char *)s.c_str()) @endcode
|
||||
|
||||
- The result of @c c_str() can not be cast to @c char* but only to @c const @c
|
||||
- The result of @c c_str() cannot be cast to @c char* but only to @c const @c
|
||||
@c char*. Of course, modifying the string via the pointer returned by this
|
||||
method has never been possible but unfortunately it was occasionally useful
|
||||
to use a @c const_cast here to pass the value to const-incorrect functions.
|
||||
|
@@ -36,7 +36,7 @@ There are two ways to generate an ID. One way is to start at a negative
|
||||
number, and for each new ID, return the next smallest number. This is fine for
|
||||
systems that can use the full range of negative numbers for IDs, as this
|
||||
provides more than enough IDs and it would take a very very long time to run
|
||||
out and wrap around. However, some systems can not use the full range of the
|
||||
out and wrap around. However, some systems cannot use the full range of the
|
||||
ID value. Windows, for example, can only use 16 bit IDs, and only has about
|
||||
32000 possible automatic IDs that can be generated by wxWindow::NewControlId.
|
||||
If the program runs long enough, depending on the program itself, using this
|
||||
|
@@ -43,7 +43,7 @@ some simple explanations of things.
|
||||
the minimal size.
|
||||
|
||||
@li @b "Maximum Size": just like for the minimal size, the maximum size is normally
|
||||
explicitely set by the programmer with the wxWindow::SetMaxSize() method or
|
||||
explicitly set by the programmer with the wxWindow::SetMaxSize() method or
|
||||
with wxWindow::SetSizeHints().
|
||||
Top-level windows such as wxFrame will not allow the user to resize the frame above
|
||||
the maximum size.
|
||||
|
@@ -1792,7 +1792,7 @@ wxWizardPageSimple classes. They both support the following properties
|
||||
@endTable
|
||||
|
||||
wxWizardPageSimple pages are automatically chained together; wxWizardPage pages
|
||||
transitions must be handled programatically.
|
||||
transitions must be handled programmatically.
|
||||
|
||||
|
||||
@section overview_xrcformat_sizers Sizers
|
||||
|
Reference in New Issue
Block a user