Add the usual handlers for '-', '+' and '*' keys. The last one is
especially convenient, as it does something that couldn't be easily done
at all interactively before.
This convenient method allows to expand all children of the item
recursively.
This is directly supported by both native implementations, so it makes
sense to have this in wxDataViewCtrl itself, even if it could be also
(less efficiently) implemented in the user code.
Ensure that vertical rules extend to the bottom of the window on the
non-first page of the control too.
This was probably broken in 5ae2a8ebb8 (Simplify API for extending
wxListCtrl background display, 2020-11-09).
Closes https://github.com/wxWidgets/wxWidgets/pull/2130
Replace SetListRulesAlternateColourOnBlank() taking 2 arguments, with
the second of them being used only when the first one is true, with a
simpler but still sufficient ExtendRulesAndAlternateColour(bool).
Make the new method virtual and define it as doing nothing in
wxListCtrlBase class, so that it's still available, even if currently
not implemented, in wxMSW.
Also simplify the implementation, fix style problems and other minor
improvements.
Previously they were both limited to the part occupied by the items
only, add a new method allowing to extend them to the whole client
window area.
See https://github.com/wxWidgets/wxWidgets/pull/2106
Unlike wxGridCellDateRenderer, which already did it, the editor class
always got the cell value from the table as a string, even if the table
supported returning the dates directly.
Fix this by using the same code in the editor as in the renderer, which
required a further refactoring in order to make it reusable: the helper
TryParseDate() was replaced with TryGetValueAsDate() and DateParseParams
was added to allow overriding the arguments passed to it in the
overridden wxGridCellDateTimeRenderer::GetDateParseParams().
This is needed to allow editing the cells using wxGridCellDateRenderer
with a custom format, otherwise the editor might parse the contents of
the cell differently from what is actually shown.
In particular, this ensures that using "date:%d.%m.%y" (or any other
custom format) as "cell type" works correctly, which wasn't the case
before.
For the tables that store dates as strings, we must use the specified
format for interpreting the table data, as otherwise we could confuse
the user by showing it incorrectly: for example, if "%d.%m.%y" format is
used, "01.03.02" should really mean 2002-03-01, but it was parsed as
0002-01-03 by ParseDate() which had no choice but to guess the order of
data components.
This fixes a bug due to a typo in ab02d36e10 (Account for vertical
alignment in wxGetGridCheckBoxRect() too, 2019-11-22) which used the
vertical component of a wrong object and so didn't actually offset the
checkbox by its size from the bottom of the cell rectangle, as it should
have done.
Closes#18907.
This reverts the changes of 4dc78a33e0 (Fix adding items to a never
opened branch of generic wxDataViewCtrl, 2018-01-17) which was supposed
to fix a problem which doesn't seem to be reproducible any longer (and,
unfortunately, wasn't recorded in the commit message back then), but
introduced another problem instead: postponing adding the node to the
tree didn't work correctly in case of depth-first model traversal in the
user code calling ItemAdded() for all the items, as in this case the
next call to ItemAdded() for a child of the item that wasn't added to
the tree because its parent hadn't been opened yet, would result in
adding this item and all its siblings to the tree when FindNode(parent)
would be called. And this, in turn, would result in the siblings of this
item being added to the tree twice.
Adding a test reproducing this problem is difficult, as we don't have
any way to check the internal state of wxDataViewMainWindow from the
outside, so this commit still doesn't do this, unfortunately.
Closes#18405.
GetItemByRow() returned a valid row even for an item which was collapsed
which is clearly inappropriate for its use in GetItemRect(), which is
supposed return an invalid rectangle if the item is not visible. It also
might be inappropriate in other cases, but this is not totally clear and
it seems like it is supposed to return a valid row even for collapsed
items at least sometimes, so just make its behaviour conditional by
adding a new flags parameter to GetItemRect() and to Walker() helper
used by it itself, so that it could skip over collapsed items.
Update the test to show that it succeeds now even when the item is
present in the tree, as it only passed before because the item had never
been expanded at all, and so wasn't really present in the tree
structure and the updated test would have failed without the changes to
the code in this commit.
Remove support for Borland C++ compiler, it wasn't tested since a long
time and probably didn't work anyhow and there was no interest in
keeping support for it since many years.
See https://github.com/wxWidgets/wxWidgets/pull/2087
Avoid sending spurious wxEVT_LIST_ITEM_{FOCUSED, SELECTED, DESELECTED}
events and make the generic version consistent with the behaviour of the
native wxMSW one.
Also add/extend the tests and slightly improve the sample.
Closes https://github.com/wxWidgets/wxWidgets/pull/2044
Also update the test to avoid assuming that wxBitmapComboBox inherits
from wxComboBox, which now allows it to build (and pass) on all
platforms.
Closes https://github.com/wxWidgets/wxWidgets/pull/2057
Draw wxTextCtrl focus ring natively on Mac.
Add wxWindow::EnableVisibleFocus() to explicitly control the focus ring
visibility if necessary.
See https://github.com/wxWidgets/wxWidgets/pull/2037
If a Caret is default-constructed, the width and height are still 0,
and the wxBitmap::Create implementations expect valid sizes.
The same applies for the bitmap after a size change.
NSTextView does not natively show a focus ring by default, and it is
extremely rare thing to do in native applications.
Don't do it in wxTextCtrl either.
NSTextView doesn't display focus ring by default, which is why wxOSX
did draw it manually, but this behavior can be overriden since OS X
10.3 with NSView.focusRingType property.
The HITheme-based rendering suffered from a number of non-nativeness
issues:
- didn't respect macOS 10.14+ accent colors
- not animated as the native focus ring
- subtly different shape of the outline
- noticeably different outline shape on macOS 11
Remove NeedsFocusRect() and associated workaround for manually drawing
focus ring inside NSTextView (i.e. multiline text controls). This
private interface was only used for wxTextCtrl and nothing else, so
this shouldn't have any impact elsewhere.
Simplify the code of wxGrid::DoGridCellLeftDown() and make it more
correct by using m_cursorMode instead of duplicating (not 100%
correctly) the logic used to set it in DoGridMouseMoveEvent().
If the assumption that m_cursorMode is already set by the time
DoGridCellLeftDown() is called turns out to be wrong, e.g. when wxGrid
is used on touch screens, we would need to refactor these functions to
extract the code determining m_cursorMode from the mouse location into a
separate function that would be called from both.
Note that this commit is best viewed with "git diff -w" to see how little
has really changed.
Generalize the changes of 415f080c80 (Split wxGrid RANGE_SELECT event
into SELECTING and SELECTED, 2020-07-27) to the case when the mouse is
dragged over row or column headers: also send SELECTING events while
dragging and a SELECTED event at the end, whether it's due to releasing
the mouse button or losing mouse capture.
Change the logic in ChangeCursorMode() to explicitly exclude the modes
for which the mouse should not be captured, as CaptureMouse() should be
called in most cases (and ideally for all of them in the future) and do
capture it for WXGRID_CURSOR_SELECT_{ROW,COL} too, if only to be
notified about mouse capture loss.
Pass the same eventType ExtendCurrentBlock() is called with to
SelectBlock() called to perform the initial selection to ensure that
wxEVT_GRID_RANGE_SELECTING is sent while dragging instead of the
unexpected wxEVT_GRID_RANGE_SELECTED (in addition to the expected one
sent at the end when the drag is over).
Instead of just passing a boolean flag indicating whether
wxEVT_GRID_RANGE_SELECTED should be sent, pass wxEventType to send, with
wxEVT_NULL being interpreted as "don't send anything".
No real changes yet, but this will allow using the existing functions to
send wxEVT_GRID_RANGE_SELECTING and not only SELECTED in the upcoming
commits.
Remove m_isSelecting and StartSelecting() from wxGridSelection to avoid
inconsistency of wxGridSelection selecting mode state with wxGrid state,
as wxGrid already has m_isDragging field which tells it if the selection
state is final or not.
Instead, just allow wxGrid to specify the event to send from
ExtendCurrentBlock().
We still need a separate EndSelecting() for sending the final
wxEVT_GRID_RANGE_SELECTED event, but send it only for the last selection
block, and not all the selected blocks, as this makes more sense (there
should be one SELECTED event for each block and it was already sent for
the other blocks before) and is consistent with the events generated
when performing the same actions from keyboard.
This will allow the applications that are only interested in the final
selection to ignore the intermediate SELECTING events, which are now
sent as soon as the selection changes while dragging the mouse, and only
handle the final SELECTED ones, when the drag is over.
