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.
Previously, the editor was hidden if the left mouse button was pressed,
but not for the right (or any other) button, which could result in a
confusing situation when a user could select a command from a context
menu shown from the corresponding event handler and start editing
another item while the current one was still being edited too.
This was already the case if the item was not visible because its parent
was not expanded, but now make it also true for the items which are not
visible due to the current scrollbar position.
Add unit tests checking for this and also verifying that GetItemRect()
returns the coordinates in the physical window coordinates.
Rename its m_ret field to a more clear and more consistent with
RowToTreeNodeJob::m_current name and also make m_current, unlike m_ret,
0-based from the beginning instead of having to subtract 1 from it in
GetResult().
There should be no changes in the class behaviour.
Get rid of hardcoded, without any explanation, "-2" value passed to this
class ctor and instead initialize its m_current member to -1 and explain
why do we do it and increment it after processing the current item, not
before, in operator().
No changes in behaviour.
Calling GetItemRect() for an item which was not currently visible
because its parent was collapsed resulted in silently returning the
value for a wrong value before the recent fix to GetRowByItem() and in
a crash after it because GetTreeNodeByRow() returned null when passed
invalid row index.
Fix this by explicitly checking whether the item is shown and just
returning an empty rectangle instead.
Also document this behaviour and add a unit test for it.
If the item was not found at all, which can happen if all its parents
are not expanded, this function still returned a valid but completely
wrong row index.
This affected many functions which could call it for the items which
were not necessarily visible, i.e. all of them except for the event
handlers as events can only affect the visible items, including but not
limited to SetCurrentItem(), all the selection-related functions, all
the expansion-related functions, EnsureVisible(), HitTest() and
GetItemRect().
It doesn't make much sense to use an "unsigned int" variable only to
cast it to int everywhere where it's used. Just make it "int" from the
get go and have a single cast to int in the caller.
Also make m_row const as it never changes.
RefreshRow() is called very frequently, and in particular after every
ItemChanged notification. Calling GetEndOfLastCol() in it repeatedly is
extremely inefficient in presence of auto-sizing columns, and doesn't
make much sense anyway - controls with significant space unoccupied by
columns are rare, and rendering of such unused space is efficient (just
background erase). It is therefore more performant to simply refresh
the entire row instead of repeatedly and expensively calculating the
smallest rectangle that needs repainting.
Fixes previously wrong calculation of the refreshed rectangle in
RefreshRows() in the process.
Fixes major performance regression introduced in
77c7c80696.
Closes https://github.com/wxWidgets/wxWidgets/pull/970
