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 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.
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 already worked with the generic version, but silently failed with
wxMSW, so make it work with wxMSW too as it doesn't cost much and makes
wxListCtrl behave in the same way under all platforms.
Also document that SetImageList() can be used before the window is
created.
This control was removed during the Carbon code removal in commit
5ba67c67e4, so the system option
does nothing now (and was only mentioned in the documentation
and the sample).
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
Since OS X 10.12 it has been named macOS so it makes sense
to reference it in documentation as such, even when it
sometimes refers to older versions which were called (Mac) OS X.
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.
Notably mention that showing modal dialogs won't work in this case.
Also link to this explanation from wxListCtrl documentation as
wxEVT_LIST_ITEM_SELECTED is one of the perhaps less expected cases in
which this problem arises.
See #9973.
It doesn't make sense to return anything else than an empty rectangle
when querying the icon rectangle of the sub-items that can't show any
icon.
Also document this behaviour, just in case it's not obvious.
In InsertColumn(long, const wxListItem&) a line was split inside a
referred overloaded method signature which prevented doxygen to
recognize and link the referred method.
In InsertColumn(long, const wxString&, int, int) non-existing
Insert(long, const wxListItem&) overload was referenced instead of
InsertColumn(long, const wxListItem&).
Clsoes https://github.com/wxWidgets/wxWidgets/pull/1279
No real changes, just clean up sources by removing trailing spaces from
all the non-generated files.
This should hopefully avoid future commits mixing significant changes
with insignificant whitespace ones.
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.
This method can be used to change the list view header appearance.
Add the method declaration, documentation, show it in the sample and implement
it for wxMSW (only, for now).
The two existing structs were completely identical, just replace them with a
single wxItemAttr.
Notice that wxDataViewItemAttr is not quite the same, although pretty similar,
so it remains separate for now. It would be nice to combine it with this one
too in the future, e.g. to make it simpler to make items bold in a wxListCtrl.
wxSystemThemedControl allows to use the "system theme" (i.e. the theme used by
the system applications such as file manager and which can, surprisingly, be
different from the default one). Currently it is only implemented for wxMSW
and does nothing under the other platforms.
Use wxSystemThemedControl for wxDataViewCtrl, wxListCtrl and, optionally, if
wxTR_TWIST_BUTTONS style is specified, wxTreeCtrl to give them more native
appearance under MSW.
Closes#16414.
This port is not used and is not being worked on, so remove it to reduce the
amount of the code which needs to be updated for every global change.
Also remove tests for VisualAge compiler which isn't used since ages.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76533 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Any reasonable person expects the sort callback to receive the indices of the
items, but it doesn't: it's passed the client data associated with them
instead. Make it even more noticeable in the documentation.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@76205 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
