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.
It seems that LVS_EX_DOUBLEBUFFER is required for the system theme to work
correctly, otherwise multiple display glitches can be observed by simply
changing the selection in the list.
Closes#17177.
In principle, calling DeleteAllItems() on a virtual list control doesn't make
sense at all, but apparently people actually do it and it mostly works except
that the controls scrollbars are not updated, so add a call to Refresh() to
update them too, for consistency with DeleteItem() which similarly doesn't
make sense for virtual controls but where we also explicitly support them for
some reason.
Finally really fix the problem with an explicit cast to WPARAM needed to fix
the warning for MinGW but provoking a warning with MSVC: this cast was added
in 612bbde52f, reverted in
77cfdec054 and added back in
36e5a9a7c4 and so we were back to having
warnings in MSVC 64 bit builds.
Work around them by defining NO_ITEM constant differently for MinGW and MSVC
to satisfy both of them.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
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.
TDM-GCC 4.9.2 gave many of these warnings for the calls to Windows common
controls macros, avoid them by adding error reporting where it makes sense or
just suppressing the warning by explicitly casting to void elsewhere (e.g. for
the macros which have no meaningful return value at all or return something
that we're not interested in instead of just success/failure indicator).
Reuse wxListCtrl::SetTextColour() instead of calling ListView_SetTextColor()
from wxListCtrl::SetForegroundColour().
This ensures that the two functions behave consistently, e.g. they now both
use palette-relative colour instead of a raw RGB value in the case of the
latter method as before. This probably doesn't change anything in practice
nowadays.
This simplifies the code and fixes the bug with GetItemCount() returning wrong
(old) value in wxEVT_LIST_INSERT_ITEM event handler as m_count wasn't updated
by then yet.
Closes#3793.
