The old API seems unnecessarily complex, it is simpler to just let the
application call ShowSortIndicator() itself from its
wxEVT_LIST_COL_CLICK handler, which needs to be defined anyhow in order
to actually sort the items, rather than require it to enable sort
indicator, explicitly set it initially and then remember to not set it
any longer in response to the column clicks.
Also make RemoveSortIndicator() non-virtual and implement it simply as
ShowSortIndicator(-1) because this actually simplifies the code too.
It doesn't seem right for ShowSortIndicator() to silently do nothing if
EnableSortIndicator() hadn't been called before, so make it enable the
sort indicators if they hadn't been enabled yet.
The alternative would be to assert in this function, but this seems less
useful.
Also add some comments to wxMSW version.
Don't do anything at all if nothing changes and if the indicator does
change, refresh only the header window and not the whole list control,
which seems unnecessary.
Don't use "const int" or "const bool" for parameter types, the "const"
here is ignored and using it is inconsistent with all the rest of the
library.
No real changes.
There doesn't seem to be any reason to not show sort indicators in the
columns of virtual list controls, so simply remove the test for
IsVirtual() in DrawSortArrow().
This allows d8ec0aa001 (Support sort indicators in wxListCtrl header,
2021-11-28) to work for wxListCtrl with wxLC_VIRTUAL too.
Put the code common to all wxListCtrl implementations in the common base
class instead of duplicating it in wxMSW, wxQt and generic versions.
No real changes yet, this is a pure refactoring which prepares for the
upcoming changes.
Don't set default width every time the column is updated, as it happens
e.g. when it's clicked by the user, but only when it is created, by
moving the code added in 96d36383bd (Use sensible default column width
in generic wxListCtrl too, 2021-08-17) from SetItem() to the ctor of
wxListHeaderData.
Closes#19256.
Sub-item hit testing is still not implemented, but at least initialize
the output parameter to the documented value instead of leaving some
junk in it.
Right clicking item always selected it, which made it possible to have
multiple selected items even in a single-selection control.
Restore HighlightAll(false) erroneously removed by fedc80eee3 (Improve
selection and focus events generation in wxGenericLisCtrl, 2020-09-06)
to fix this and restore the correct old behaviour.
Note that even in multiple selection mode right clicking a previously
unselected item should still clear the selection, as it does it in the
other GTK programs (and also under MSW).
Set width of the new columns to wxLIST_DEFAULT_COL_WIDTH and not 0 in
the generic version: this is more compatible with the MSW version and
more useful.
Document that omitting list column width in XRC results in columns of
default, rather than null, as previously, width.
The same value of 80px was used in both the generic and MSW versions of
wxListCtrl, so introduce a symbolic name for it and define it only once,
similarly to how it's already done for wxDVC_DEFAULT_WIDTH and
WXGRID_DEFAULT_COL_WIDTH.
No real changes.
This wasn't done since the changes of c1c4c5516c (fixed unwanted owner
data accesses in virtual list ctrl, 2001-08-07), but there doesn't seem
to be any reason to avoid accessing the item in SendNotify() (any more?)
and if we ever did generate events for all the items in a virtual list
control, this would be already a problem, even if we didn't access the
line info from here.
So just revert the check for !IsVirtual() and always fill the item in
the generated event to make the behaviour of the generic version
consistent with the MSW one and slightly more useful.
See https://github.com/wxWidgets/wxWidgets/pull/2456Closes#19235.
Use 2 separate functions instead to make the code more clear, as passing
false for indicate the refresh shouldn't be done was quite confusing.
Also get rid of a separate RefreshAll() which was called only from
RecalculatePositions().
No real changes.
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
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
It wasn't used since f8252483ec (Applied patch [ 803473 ] wxListCtrl
header height bugfix, 2003-09-11) but remained, commented out, in the
code for some reason.
This test was apparently supposed to check if the mouse was inside the
header, vertically, but this should always be the case unless the mouse
is captured and when it is captured in this code, m_isDragging is set to
true meaning that the code in the "else" branch of the test for it can't
be executed at all, so checking the vertical position seems completely
unnecessary.
Worse, it was actively harmful when using GTK 2 with DPI scaling, as in
this case the height of the window could be different from 22 (e.g. 44
for 2x scaling).
Closes#18713.
In the case when a listctrl is clicked outside of any item, the item is
visually deselected, and it is logical that a DESELECTED is sent.
For non-virtual lists this would happen, but for virtual lists it would
either happen or not happen depending on implementation (MSW/generic)
and mode (single/multi). From now on the DESELECTED event is always sent.
No real changes, just remove the old code using wxINVERT logical
function which doesn't work with wxGTK3/wxMac anyhow and so is really
not worth keeping.
See #16890.
This is unexpected, so add the check for the modifiers, as is done in
generic wxDataViewCtrl, to only accept the "real" Enter here and not
Ctrl-M sending the same key code.
Closes#17458.
Autosize the column to fit its contents or its label width if there are
no items when its divider is double clicked.
This is consistent with wxMSW behaviour and is generally convenient.
Closes https://github.com/wxWidgets/wxWidgets/pull/1573
Use wxVector<wxListLineData*> instead of WX_DECLARE_OBJARRAY().
This modernizes the code and allows to get rid of the static variables
previously used for sorting as now we can use std::sort().
Closes https://github.com/wxWidgets/wxWidgets/pull/924
For some reason lost in the depths of time (but probably just a typo)
(but probably just a typo) (but probably just a typo) (but probably just
a typo), SetItem() overload taking the column index returned "long" and
not "bool", even though the actual return value was always "true" or
"false" (or even just always "true" in the case of the generic version).
Change it to return "bool" for consistency with the other overload and
because this just makes more sense and shouldn't break any existing code
due to the implicit conversions between bool and long.
Also document the return value meaning.
Closes#18153.
wxListHeaderWindow event coordinates don't need to be adjusted, as it's
positioned at (0, 0) of its parent window anyhow, but wxListMainWindow
events do need to be adjusted to use the parent window coordinates, as
it's the only window that should be seen by the outside code -- and also
for consistency with the native MSW version.
This corrects the changes originally done in
651d7a1ff8
See #18133.
There doesn't seem to be anything wrong with just showing the popup menu
in this window itself and this avoids the need to do any coordinate
adjustments, which didn't work correctly for the menus shown over the
header window after the previous commit (and hadn't worked correctly for
the menus shown over the non-header area before it).
See #18133.
The position was off by the header height due to a missing translation
between wxGenericListCtrl and wxListMainWindow, in which the menu is
actually shown, coordinates.
Closes#18133.
