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.
Appending an item in the listctrl sample results in two horizontal lines
drawn next to each other while they should be overlapping. Fix by drawing
only the bottom line of each item instead of skipping the first one
(should have been the top visible item since
6443de0263) and drawing the last one in the
list (should have been bottom visible item).
Since 9eaba69276 a fix was added for leaving
behind trailing pixels when resizing a column in a ListCtrl that uses
wxLC_VRULES. This fix is only needed for ComCtl32.dll versions prior to
6.0. Make the fix conditional and explain the (rare) conditions under
which the problem still occurs.
Also see #747.
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.
When not using MinGW the value NO_ITEM (-1) is passed as an item count to
the macro ListView_ApproximateViewRect. While Windows/Platform SDKs since
at least 6.0a cast the argument to (only!) a WPARAM, older ones such as
5.0 don't which results in a signed/unsigned mismatch (converting -1 to
WPARAM, which is an UINT_PTR).
Fix by always casting to WPARAM when using ListView_ApproximateViewRect.
Also use a value of -1 again instead of NO_ITEM because the latter is a
bit of a misnomer in this case (as it refers to the total number of items
in the control) and to reduce the risk of the cast being removed in the
future as well as differentiate it from the MinGW headers issue.
Note that this is a different casting problem than with other ListView_XXX
macros such as ListView_GetNextItem (which cast to int first and then to
WPARAM) where casting to WPARAM results in a warning with WIN64 builds.
That situation does not apply to ListView_ApproximateViewRect.
Regression since 00c63cfd3a.
For ComCtl32 prior to 6.0 all text labels in wxListCtrl need to be re-assigned when new wxImageList is set in order to position them correctly within the control.
When computing the best control width from height, or vice versa, don't
account for the border size twice, once inside ListView_ApproximateViewRect()
and another time in our own code in the base class.
As we can't change the former, just compensate what the latter does by
returning the best width or height of the client part of the control, as
indicated by the DoGetBestClient{Height,Width}() methods names.
This constant is defined in wx/msw/missing.h if it's not defined, so testing
for whether it's defined here doesn't make sense -- and the comment about not
using it under Windows CE which is not supported any more anyhow doesn't make
sense neither.
