In a native up-down control hexadecimal numbers are always unsigned (see
UDM_SETBASE message documentation) so we need to prevent:
- Setting a range including negative values if base == 16.
- Setting base != 10 if current range includes negative values.
See #18805.
No real changes, just move m_textLines and m_heightLine from wxTipWindow
to wxTipWindowView as they were only used by the latter and so can just
as well be its members.
Also use this as an opportunity to replace wxArrayString with wxVector.
It doesn't seem to make sense to provide wxFrame-based implementation of
wxTipWindow, if anything we should use similar code to implement
wxPopupTransientWindow itself on the platforms not providing it.
So simplify wxTipWindow code by leaving only a single implementation,
using wxPopupTransientWindow. This should have arguably been done back
in 8962e1d938 (wxTipWindow is now a wxPopupTransientWindow instead of a
wxFrame., 2001-11-30) which introduced the use of wxPopupTransientWindow
in this code.
Allow wxPopupTransientWindow to work without wxPU_CONTAINS_CONTROLS too
in wxMSW and don't use wxPU_CONTAINS_CONTROLS by default, notably
allowing wxTipWindow to be shown without stealing focus.
See https://github.com/wxWidgets/wxWidgets/pull/1942Closes#18636.
This is embarrassing, but the iterator returned by this method seems to
have always been wrong, ever since it was added back in 946954d3bf
(Added reverse iterator to wxVector<T>, 2008-09-16). Moreover, it was
also broken in its const_reverse_iterator counterpart where it was
copy-and-pasted in f7ef20685f (Add wxVector<>::const_reverse_iterator,
2013-05-08).
Finally fix this to return the correct value and add at least a simple
unit test check that this method behaves as expected.
We probably could drop support for some gcc 4.x versions too, but we
definitely don't need to support gcc 3.x any longer and not doing it
simplifies the code a bit, so just assume gcc >= 4.
Closes https://github.com/wxWidgets/wxWidgets/pull/1943
Don't duplicate practically the same code in all ports, just add m_paths
itself to the base class. The only drawback of doing this is that it's
unused in the ports not (yet) using it, but this saves enough code in
the aggregate to be worth it.
This is confusingly similar to std::string::empty() which doesn't do the
same thing, so prefer using clear() instead.
And simply remove Empty() calls before the assignment, as they're
useless.
No real changes.
OSX 10.11+ doesn't actually display the title, so update documentation
to reference SetMessage instead. For pre-10.11 override the SetTitle
method to set the title of the NSOpenPanel instead of the window.
Also change so the directory is not updated unless it is provided.
Closes#15143.
Add wxDirDialog::GetPaths() similar to the existing member of
wxFileDialog with the same name and also taking, for consistency,
wxArrayString as the output parameter.
Popups not using this style work too now (since the parent commit), so
this style should be used only if the popup actually requires focus and
not always, unconditionally.
Turn on this style explicitly in the sample which shows a popup window
with wxTextCtrl inside it (which requires focus to work).
Popups not using wxPU_CONTAINS_CONTROLS were not automatically dismissed
at all any longer, as the only auto-dismissal mechanism related on
getting WM_ACTIVATE, which they never did, so implement a different
logic for dismissing them: do it on any change of focus and also any
mouse press (but not move and not key press neither).
This will allow not using wxPU_CONTAINS_CONTROLS for popups that don't
need focus, but still must disappear on their own.
We need to set the new owner for the TLW, instead of using the new
parent as the actual parent, in the MSW sense, as this results in a
weird situation in which the TLW becomes a child (i.e. non-TLW) window.
Closes#18785.
Add a new string fragment type for whitespace and punctuation which needs
to be assessed separately from letters and symbols.
Use wxUint64 instead of long for storing the value for numeric fragment.
Use collate instead of compare for non-numeric fragments.
Change names for the public comparison functions: wxWidgets provided function
is now named wxCmpGenericNatural() and for common public use is wxCmpNatural()
which calls a native function in wxMSW and wxCmpGenericNatural() elsewhere.
Try harder in wxCmpNaturalGeneric() if wxRegEx is unavailable: do not
just make a simple string comparison, but perform a case-insensitive
collation.
Make some other changes to simplify and possibly speed up the code.
Provide API for dealing with m_lastKeyDownEvent instead of using it
directly and extend it to avoid sending duplicate events for keys which
are mapped to multiple selectors, such as Ctrl-O with the default key
bindings.
Closes https://github.com/wxWidgets/wxWidgets/pull/1928
Under MSW it is possible to restrict the native font dialog to showing
only scalable fonts only, disallowing the raster fonts, so add a method
to wxFontDialog exposing this functionality in wxWidgets API.
Closes https://github.com/wxWidgets/wxWidgets/pull/1926Closes#16988.
The changes of e6e6dbe077 (Fix problems due to deleting grid cells in
the event handlers, 2020-05-02) fixed the bug (see #18731), but
introduced another one in place: if wxEVT_GRID_CELL_CHANGED handler
deleted any cells, wxGrid code could mistakenly restore the "old" cell
value (actually it restored the value for a different cell, as the
current cell coordinates necessarily changed too in this case).
This bug became more visible after the addition of activatable editors
as the new code asserts, instead of trying to restore the old value, if
wxEVT_GRID_CELL_CHANGED is vetoed, which also resulted in asserts if the
handler deleted the current cell instead.
Fix this by separating the cases of event being really vetoed and of the
event handler deleting the cell for which the event was generated and
handle the latter separately from the former where it matters.
This commit is best viewed ignoring whitespace changes.
This is more verbose, but also much more clear (and so allows to remove
some previously necessary comments).
No real changes, even keep the same values for the enum elements as were
previously used: this is probably unnecessary but do it just to minimize
changes.
This makes it much more convenient to use interactively, as the cell
value is toggled immediately and, even more importantly, the UI doesn't
enter the confusing editing mode which doesn't look any different from
the normal grid appearance except for the current cell border absence.
Note that we still keep support for classic in-place editing to preserve
compatibility with the code which calls EnableCellEditControl()
explicitly and expects an editor to be shown, but perhaps we could
switch to using only activation in the future.
Add a helper class making it easier to define activation-only editors
and use it to implement MyGridStarEditor in the sample, showing a
typical example of using such editor.
This is useful for editors which don't really need to show any control
as they can change their value directly and will be used to reimplement
wxGridCellBoolEditor in the upcoming commits.
No real changes, just factor out code for getting and setting the grid
cell value as bool from {Begin,Apply}Edit() to {Get,Set}GridValue() to
make it possible to reuse these functions in the upcoming commits.
This commit is best viewed with the --color-moved option.
Although this variable, and a check for it in OnKeyDown(), was present
since the first version of this code added back in f85afd4e46 (Added new
wxGrid classes[...], 1999-10-06), there doesn't seem to be any
indication that it has ever been needed, so remove it to simplify the
code and make it possible to add early returns to this function easily.
No real changes yet.
It ended up returning the result of the base class method anyhow, just
after doing a lot of unnecessary work, so this commit shouldn't change
anything, but should significantly speed up this function.
We may want to explore the possibility of implementing this method
natively using GetPeer()->IsVisible() later, as it could be faster than
our own implementation, but we need to ensure that this always returns
the same result as before, which might not be the case when the TLW is
in the process of being shown or hidden, so don't do this for now.
Closes https://github.com/wxWidgets/wxWidgets/pull/1911Closes#18645.
Checking the new function return value is simpler than checking the
value of m_cellEditCtrlEnabled after calling EnableCellEditControl().
Do this now also when starting editing using the mouse, as it was simply
forgotten before and so StartingClick() was still called even if editing
was vetoed.
Also add DoDisableCellEditControl(), but this one exists purely for the
symmetry.
This also allows to reset m_cellEditCtrlEnabled earlier, as we don't
have to keep it true for the duration of HideCellEditControl()
execution.
No real changes, as with the previous commit, this one is best viewed
ignoring whitespace changes.
It doesn't make sense to perform the checks in ShowCellEditControl()
when it's called from EnableCellEditControl() and this makes the code
unnecessarily fragile as m_cellEditCtrlEnabled needs to be set at just
the right moment for it to work correctly.
Call the new DoShowCellEditControl() instead and perform the checks only
in the public function, for compatibility.
Also note in a comment and the documentation that ShowCellEditControl()
is not very useful anyhow and that EnableCellEditControl() should most
often be used instead.
No real changes (the commit is best viewed ignoring whitespace changes).
This check was introduced back in 283b7808d8 (added support for readonly
cells and 3d border drawing, 2000-02-16), but was wrong even then and
remained wrong ever since: we must not set m_cellEditCtrlEnabled to true
when the current cell is read-only, so there is no need to check for the
latter condition if m_cellEditCtrlEnabled is indeed true.
Ensure that we really never erroneously set m_cellEditCtrlEnabled for
the read-only cells by replacing an wxASSERT_MSG checking for this in
EnableCellEditControl() with wxCHECK_RET().
Also explicitly document this function precondition, also added back in
b54ba67107 ([...] added CanEnableCellControl() and use it before calling
EnableEC, 2000-02-17) but never documented so far.
Apply the utility from https://github.com/codespell-project/codespell/
to fix spelling issues in the headers under both include and interface
directories and add a file with a couple of exceptions.
The exact command line used was:
$ codespell -w -I misc/scripts/codespell.ignore -i 3 in*
This allows to fold the last DoSaveEditControlValue() call into this
function, so that it's only called from DoAcceptCellEditControl() or
from SaveEditControlValue() (which is public, and hence can't be
changed, even if its behaviour doesn't make much sense).
This commit means that m_cellEditCtrlEnabled is now reset to false when
AcceptCellEditControlIfShown() is called, which was not the case before,
but this seems to make sense, as we shouldn't be just hiding the editor
while leaving it enabled, and, also, doesn't really seem to change
anything as hiding the editor indirectly results in a call to
DisableCellEditControl(), via wxGrid::OnHideEditor(), and so it was
actually already reset before -- but now this happens slightly earlier
and more explicitly.
This is just another refactoring in order to avoid duplicating calls to
HideCellEditControl() and SaveEditControlValue() in several different
places.
Also call DoSaveEditControlValue() because if the editor is shown, it is
also necessarily enabled and there is no need to check for this.
