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.
We accidentally ended up with two functions doing the same thing, since
DoGetBorderSize() was added in 743b426605 (Added DoGetClientBestSize()
and use it for a couple of controls in wxMSW., 2009-06-22), as we
already had GetWindowBorderSize() added even earlier in 333d70525c
(added wxWindow::GetWindowBorderSize(), 2006-11-25), so remove the
redundant non-public function and use GetWindowBorderSize() everywhere.
This does change the behaviour of GetWindowBorderSize() in wxMSW, wxGTK
and wxUniv, as it now does what DoGetBorderSize() used to do, but this
should be an improvement, as DoGetBorderSize() implementation was more
precise.
This is more concise and less error-prone than multiplying/dividing DPI
values manually.
No real changes except, maybe, in wxSlider code where the rounding was
done differently before for some reason.
This reverts commit 374db28747 (Fix wxMSW ListCtrl drawing of horizontal
rules for new items, 2016-05-04) and also commit bb3177dd3b (Avoid
infinite repaint loop in wxListCtrl with wxLC_HRULES, 2020-07-24) which
fixed one problem with the original change, but not all of them, as it
was still easily possible to get into an infinite repaint loop.
So just return to the simplest and not too bad, even if not optimal,
solution of refreshing everything after changing a column width when
using horizontal rules.
See #17158, #18850.
Closes#18927.
This can take multiple seconds in big lists, meanwhile the UI is frozen at the
display border. Adjust the font of the attribute to the DPI when it is used for
drawing.
A virtual wxListCtrl with wxLC_HRULES which wasn't fully visible on
screen, i.e. didn't fit into the visible area of its parent window
(which included the case when the parent was a wxScrolledWindow, for
which it is normal and expected not to be able to fit all of its
children) got into an infinite repaint loop because of a RefreshRect()
call inside wxListCtrl::OnPaint().
Fix this by avoiding to call RefreshRect() added in 374db28747 (Fix
wxMSW ListCtrl drawing of horizontal rules for new items, 2016-05-04),
unless the current clipping rectangle is less than the actually
effective visible width and not the full client width, which can be much
bigger.
This still doesn't ensure that we don't enter into an infinite recursion
here, so it would be even better to call RefreshRect() at most once
before the next control change, but it's not clear when exactly this
"already refreshed" flag would need to be reset.
See #17158.
Closes#18850.
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.
Set LVCFMT_IMAGE, meaning that the column just uses an image from the
image list, instead of LVCFMT_COL_HAS_IMAGES, meaning that the column
contains the image from the image list and do not set LVCF_IMAGE when
resetting the image, as this still reserved space for the (invalid)
image, resulting in an extra blank area in the column header.
Closes https://github.com/wxWidgets/wxWidgets/pull/1739Closes#18617.
This was already the case in the generic version, but wxMSW one just
silently returned 0 for invalid item index.
Make it consistent with the other platforms and SetItemState() by
checking the index in it too.
Closes https://github.com/wxWidgets/wxWidgets/pull/1702
Setting WS_EX_COMPOSITED, as the base class version does, just results
in visual artefacts and is useless, as we turn on LVS_EX_DOUBLEBUFFER
already, if it's supported, anyhow.
So don't break the display if people call SetDoubleBuffered() in the
mistaken belief that it does something useful in this case.
Resetting LVCFMT_COL_HAS_IMAGES does work and removes the image shown
in the column without leaving any space for it, unlike the previously
used version.
Closes#18523.
Do use LVCFMT_COL_HAS_IMAGES as it's the right flag to use according to
the documentation, unlike LVCFMT_IMAGE which seems to have worked only
accidentally.
See #18523.
Autosizing the column by double clicking on its separator line reset it
to the default width when the control was empty, which isn't especially
useful.
Set the column size to fit its header instead.
Closes#9926.
See https://github.com/wxWidgets/wxWidgets/pull/1573
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.
The fix for visual artefacts when resizing columns with comctl32.dll v6
introduced them when using v5 of the DLL, so apply it only conditionally
now.
See #18032, #18441.
LVS_EX_DOUBLEBUFFER doesn't seem to work correctly with comctl32.dll v5,
and results in artefacts when the control is resized, so don't enable it
for it.
Closes#18441.
This function is a just a very thin wrapper for WM_SETFONT, but it's
still better to have it rather than write casts to WPARAM and
MAKELPARAM() in several different places.
Note that this removes the assert for font validity from
wxWindow::SetFont() which really doesn't make much sense (and if we
wanted to have it, it would be better to have it for all ports in
wxWindowBase instead) and was never triggered since more than 20 years
of its existence.
Items using wxSYS_COLOUR_BTNFACE (light grey in the default theme) for
their background are, for some reason, drawn using the colour of active
selection (blue) even when the control doesn't have focus.
This is wrong, but there just doesn't seem to be any way to prevent this
from happening when using the native drawing logic other than not using
wxSYS_COLOUR_BTNFACE for the background (modifying any colour channel by
1 is enough to work around the issue). So to draw the item ourselves in
this case and hope that it remains indistinguishable from the native
appearance when not using the system theme.
Closes#17988.
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.
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.
If we don't pass these messages to it, the selected items highlight
rectangle doesn't get updated when the columns are resized when using
visual themes, as could be seen in the listctrl sample.
While this did work if the wxEVT_LIST_COL_DRAGGING event handler skipped
the event, prefer to not require doing this as things work without this
call to wxEvent::Skip() under the other platforms and even MSW with
themes disabled.
Closes#18032.
No real changes, but the code is slightly shorter, maybe more clear and
will be easier to maintain (because more difficult to break
accidentally) in the future.
Just turn off background erasing to avoid having horrible flicker which
can be seen perfectly well simply by drag-resizing a column in a list
control with non-default background colour.
See https://github.com/wxWidgets/wxWidgets/pull/374
The latest of those checks tested for w32 API 3.3, which is older than
MinGW 3.4 released which is more than 13 years old, so we can safely
drop them (let alone checks for prehistoric 0.5 w32 API).
This incidentally fixes compilation errors due to the use of
wxCHECK_W32API_VERSION() in wx/msw/winundef.h which was now (since
the changes of 8c572c0a77) included before
this macro was defined.
UpdateStyle() function was introduced in edccf428 to synchronize in
SetWindowStyleFlag() style of the control with new style flags just stored
in m_windowStyle.
In 9a8d75f1, storing directly a new flags in m_windowStyle was replaced by
the call to parent's SetWindowStyleFlag().
Because call to parent's SetWindowStyleFlag() updates both m_windowStyle
and actual style of the control for common flags (WS_*, LVS_* flags),
synchronizing the control again with UpdateStyles() is pointless (since
this function does nothing in this context).
Only wxSCROLL style flags need special care because wxListCtrl doesn't
have these styles but the control itself may have them. In order
to preserve them in the call to SetWindowStyleFlag(), we can do the trick
and request the same new scroll style as the actual physical style.
UpdateStyles() is useless now and can be deprecated.
See #17059.
The symbols in question are present at least since XP, and most of them since
Windows 2000, so remove preprocessor checks for them, they shouldn't be needed
when any remotely current compiler/SDK.
When adding a new item to a wxMSW ListCtrl that uses horizontal rules the
painting is horizontally clipped to the left of the control and the
rightmost column and the rule doesn't extend beyond that as it does when
doing a full repaint. Fix by refreshing the part to the right of the
rightmost column.
This also reverts 02c8973a57 which became
unnecessary now.
Also see #17158.
