This makes several methods that didn't have any effect before work
correctly, including SetToolTip(), whose effect is now shown in the
sample, but also SetCursor() and SetLayoutDirection().
Some methods would now actually work too well: SetForegroundColour() and
SetBackgroundColour() implementations in wxCompositeWindow apply to all
sub-windows, but in wxDataViewCtrl they are only supposed to affect the
items, but not the header, so we need to override them to prevent the
base class version from being used. It is still preferable to explicitly
disable these two methods and inherit all the other ones (including any
possibly added in the future) from wxCompositeWindow to implementing all
the methods manually in wxDataViewCtrl itself.
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.
This is more correct as saving the current width of the last column
would prevent the user from shrinking it under the last automatically
set size, i.e. the UI behaviour would change after restarting the
program, which shouldn't be the case.
Doing this required making WXGetManuallySetWidth(), which previously
existed in the generic version only, available in all ports, so do it
and also rename it to WXGetSpecifiedWidth() in the process, as this
seems a somewhat better name (it doesn't have to be manually specified,
i.e. it could also be done by the program itself or even implicitly by
wxPersistentDataViewCtrl).
Don't make this function public, at least for now, because it's not
clear how could it be useful and it might still need to be changed to
behave differently in the other ports.
This fix for disallowing shrinking the last column to nothing instead of
showing horizontal scrollbar when it became smaller than its minimum
size was wrong and is not necessary any more after the correct fix in
the previous commit.
This effectively reverts 0c90ea40c3 (Don't auto-resize wxDataViewCtrl
columns below their initial size, 2019-10-03).
See #18343.
Columns without any explicitly specified width still shouldn't be shrunk
down to 0 size by UpdateColumnSizes(), so handle them as if they were
created using wxDVC_DEFAULT_WIDTH instead -- which is what their actual
width is/would be.
This is a better fix than the one in 0c90ea40c3 (Don't auto-resize
wxDataViewCtrl columns below their initial size, 2019-10-03) and that
commit can be reverted now, as will be done soon.
See #18343.
Previously, the column was updated, i.e. wxHeaderCtrl::UpdateColumn()
was called, after the column width was changed interactively by the
user. This was unnecessary and actually harmful as it resulted in
recursion and display corruption.
Stop doing this by adding yet another width-related function to the
generic wxDataViewColumn called WXOnResize(), which just updates the
main window display, but doesn't update the header at all, and calling
it instead of SetWidth(), which does both, when the column is resized.
Closes#18245.
It's unexpected that decreasing the width of the control makes the last
column diminish in size until nothing (at least if it's minimum size was
not set), instead of showing horizontal scrollbar, so prevent this from
happening by considering the initial column width as being "manually
set", which prevents the code from making the column narrower than it
automatically.
This seems to make sense and is consistent with the handling of initial
size, which becomes "best", and hence "minimal", size of the control,
for wxWindow.
Closes#18343.
Fix the row heights after a DPI change and adjust the column widths.
Use DPIChangedEvent instead of MSWUpdateFontOnDPIChange because the child
controls (m_clientArea, m_headerArea) need to update their font sizes first.
As wxDataViewColumnList was never public, it should be fine to not
define it any more and use a vector instead.
This makes the code more clear and also marginally more efficient.
Previously, the last column couldn't be effectively resized at all, as
its size was always automatically set to the remaining width of the
window after subtracting the widths of all the previous columns. Now
this is only done if this remaining width is greater than the width
given to the column by the user or by the program.
Effectively, this means that the user can now drag-resize the column to
increase its size (at the price of showing the horizontal scrollbar).
See #18295.
This reverts commit 24054c95d8 as it
actually should be possible to increase the size of the last column,
even if this shows the horizontal scroll bar.
This basically removes the "adv" library, even though it's still
preserved for compatibility with user make/project files referring to
it.
It is done because the distinction between "adv" and "core" was never
really clear (e.g. why wxTreeCtrl was in core but wxTreeListCtrl in
adv?) and it prevented some core classes from using adv ones.
Previously this method was only available in the generic wxDataViewCtrl,
move it to the base class to make it possible calling it in portable
code and document it.
Closes#14617.
Expand() called ExpandAncestors() in the generic wxDataViewCtrl implementation
but not in the native ones, resulting in observable difference in the
behaviour: for example, the wxDataViewTreeCtrl in the dataview sample appeared
initially expanded under MSW, using the generic version, but collapsed under
GTK and OSX.
Harmonize this among all ports. This also has a nice side effect of making
Expand() less horribly inefficient as it is not recursively called by
ExpandAncestors() which it itself used to call: now ExpandAncestors() only
calls DoExpand() which is a simple function that only expands the item passed
to it and does nothing else.
Closes#14803.
Caching the best column widths broke autosizing behaviour if the column title
was updated after setting the width to wxCOL_WIDTH_AUTOSIZE.
Fix this by invaliding the column cached width if its text changes.
UpdateColumnSizes() was called whenever the control was modified in any way
since 4156e1a5c9 and it refreshed the entire
last column even if absolutely nothing changed.
Don't do this unless the last column width has really changed.
Avoid calling UpdateDisplay() unnecessarily if the column width didn't really
change. This doesn't result in anything really bad happening right now, but it
could easily result in an infinite stream of updates if the code were only
slightly different and it just seems useless to do it.
Contrary to the documentation, this method only existed in the generic
control, add it to the base class now so that the code using it could compile
when using the native ports too.
There doesn't seem to be any reason for this method to be virtual other than
preventing "virtual function hiding" warnings from gcc, so just rename it to
have a different name than the virtual EnsureVisible() inherited from the base
class instead.
Mark the overridden virtual functions as being overridden.
Also reformat some methods to put them on several lines to prevent the lines
from becoming way too long.
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.
The code was confused about the difference between the model and view columns
indices and incorrectly used the former as the latter, which could result in
an out of bound array access.
Closes#15420.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74889 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
We could keep using the column previously used for sorting even after
UnsetAsSortKey() was called on it. Ensure that this doesn't happen by
resetting the owner wxDataViewCtrl sort column index too.
Closes#15160.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@73834 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Have an explicit per-column dirty flag and use that to determine whether
we need to call wxHeaderCtrl::UpdateColumn(). Previously, the lack of
computed best width was used as an indicator, but this didn't work
correctly if some code called GetWidth() after invalidation but before
wxDataViewCtrl::UpdateColWidths() was called at idle time. This resulted
in header's column widths getting out of sync with the control itself.
Fixes#14167.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@71335 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This function is called in many places in the code with possibly invalid (i.e.
out of range) row, so handle it gracefully inside it in virtual list control
case. This is consistent with the behaviour in non-virtual case and with that
of GetRowByItem().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70717 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Provide wxDataViewCtrl::SetAlternateRowColour() to specify the colour to use
for odd rows explicitly but determine it automatically from the background
colour if no explicit colour was specified.
Closes#12834.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70576 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is more consistent with other wxDVC methods (taking column pointer
as its argument) and other DVC-like classes where the name EditLabel()
is used for similar purposes.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70377 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The sort indicator on the column previously used for sorting was only reset
when the user clicked on the column header (by wxDataViewHeaderWindow code
that explicitly called wxDataViewCtrl::SetSortingColumnIndex()) but not when
wxDataViewCtrl::SetSortOrder() was called directly.
Fix this and take care of updating everything in SetSortOrder() itself. This
makes the code simpler and also means that calling SetSortOrder() from the
program now works as expected (it resulted in having sort indicators in two
columns at once before).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69175 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
The two member functions, SetAsSortKey() and SetSortOrder(), were doing almost
the same thing but differently and the former was only used in the generic
wxDataViewCtrl implementation and not implemented in the native GTK/OS X one.
Remove SetAsSortKey() entirely and only keep UnsetAsSortKey() which is still
needed by generic/MSW wxDataViewCtrl. But only SetSortOrder() should now be
called to indicate that the column is used for sorting.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@69174 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is much more efficient than doing it immediately when adding large
number of items into a control with lots of them.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68964 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
wxDataViewCtrl::GetSelection() now always returns invalid item if more than
a single item is selected in a multi-selection control.
Also add HasSelection() and GetSelectedItemsCount() to allow checking if any
items are selected.
Updated the documentation, all ports and added a test for all these functions.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@68844 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
