It's not useful to allow dragging from the control area where there are
no items and it resulted in assert failures due to using an invalid row
in wxDataViewDropSource::GiveFeedback(), so simply don't do it at all.
Note that native GTK wxDataViewCtrl implementation doesn't do this
neither, so it also makes the behaviour more consistent.
Closes https://github.com/wxWidgets/wxWidgets/pull/1828
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.
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.
Not doing this when the last column size should have been exactly equal
to its manually set size resulted in showing the horizontal scrollbar
unnecessarily.
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.
If the width really changed, wxDataViewColumn::SetWidth() already calls
wxDataViewCtrl::OnColumnChange() (via UpdateWidth()), so it's
unnecessary to call the latter again immediately after calling the
former. And if the width didn't change, it's not necessary to call it at
all, so in either case the OnColumnChange() call can be just removed.
No real changes.
The loop computing "colswidth" (the sum of widths including last column)
actually incorrectly computed "lastColX" (the sum of widths until the
last column), fix this.
See #18295.
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.
In 8f386265dc, the width of a tree
expander is changed to the native value on the platform. But some
calculations still use guessed value (m_lineHeight) as the width. This
fixes the value, by retrieving the width using the same method as in
OnPaint().
Closes https://github.com/wxWidgets/wxWidgets/pull/1508Closes#18473.
Add wxRendererNative::GetExpanderSize(), implement it using the
appropriate theme element and use it instead of hardcoding the expander
size to 3 character widths.
Closes https://github.com/wxWidgets/wxWidgets/pull/1431Closes#18449.
This is important as enabling the system theme results in changes to the
native ListView control appearance that are not undone later even if the
system theme is disabled. Notably, the item rectangle width is reduced
by 2 pixels when system theme is enabled and it's not increased to its
original value even when it's disabled later, resulting in gaps between
items through which the control background shows, for example. This also
makes items drawn using our own HandleItemPaint() slightly, but
noticeably, larger than the items using standard appearance, which looks
bad.
All these problems can be avoided if we skip enabling the system theme
in the first place if EnableSystemTheme(false) had been called before
creating the control, so support doing it like this and document that
this is the preferred way of disabling the system theme use.
Closes#17404, #18296.
Don't call wxDataViewColumn::GetWidth() in OnPaint() for columns that
are hidden: they won't be drawn and their width won't affect anything.
The call looks deceptively simple, but may invoke best width
recalculation that can be very expensive on large models.
Apparently, ScrollTo() can be called when processing keyboard input in
the control before its initial resize and hence before scrolling is
initialized and in this case per-unit scroll units are still 0, so
dividing by them is not a good idea.
Just avoid scrolling in this case.
Closes https://github.com/wxWidgets/wxWidgets/pull/1262
Notify m_selection about the new item in all cases, not just when using
a virtual list model.
This was broken back in 36a5983f64 and
only fixed for virtual list controls, but not all the other ones, in
9f5af0a494.
The current, but not selected, item was not visually marked in any way
since the changes of 4ac0250f90 which
replaced the calls to wxRendererNative::DrawFocusRect() with the calls
to DrawItemSelectionRect() which is not called when the item is not
selected.
Restore DrawFocusRect() call in this case and also pass
wxCONTROL_FOCUSED to DrawItemSelectionRect() even though this doesn't
seem to change much in practice.
Closes https://github.com/wxWidgets/wxWidgets/pull/1089Closes#18304.
After 841c14c37c, reducing width of a
generic wxDataViewCtrl caused flickering (horizontal scrollbar
appearing and disappearing immediately) when the columns were resized
by user code to fix exactly.
Fixed by calling AdjustScrollbars() after determining column sizes. It
doesn’t make sense to call it before, because UpdateColumnSizes() may
change required width.
See #18295.
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.
The code added in 4156e1a5c9 didn't quite
work correctly because it used the old size of the window, before it was
resized, and not the new size. This was almost unnoticeable when
drag-resizing the window, but very noticeable when maximizing the
containing TLW, as could be seen on the 3rd page of the dataview sample,
for example, where the last column kept its size instead of expanding.
See #13904, #18295.
