Allow changing the colour of the label in the active and hover states to
make it possible to improve its contrast with the tab background in
these states.
Closes#18406.
Even though the data is supposed to be 7-bit here, we can make an effort
to decode 8-bit data if we get any as it can't be worse than just
throwing it away.
Closes https://github.com/wxWidgets/wxWidgets/pull/1336Closes#2793.
If accepting a socket connection failed, wxSocketImpl::Accept() used
close() to close the socket even under MSW, but it can be only used for
the file descriptors there and closesocket() must be used instead for
the sockets.
Add new (private) wxCloseSocket define and use it both here, to fix the
bug, and elsewhere to make the code more clear.
Closes#18407.
wxControl::Create() has a different signature than wxWindow::Create()
(its 6-th parameter is of const wxValidator& type instead of
const wxString&) so it cannot be invoked from the the general template of
wxScrolled<T>::Create() method. We need to move a call to T::Create()
function to a dedicated template function wxCreateScrolled() responsible
for actual creation of the scrolled window and overload it for custom
classes if necessary.
This has to be done for wxControl and from this overloaded function
wxControl::Create() can be called with rearranged parameters.
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.
Having definitions of several wxPGProperty and wxPropertyGridPageState functions in wxPropertyGrid header is misleading so they should be moved to the files with their own classes definitions for the sake of clarity.
Editor used by wxLongStringProperty is wxTextCtrl-based and it should be possible to set the limit of the length of the entered text just like it's done for such editors in another properties like wxStringProperty.
Setting the limit for the length of the text the user can enter in the text editor makes sense only for properties having text editors so in wxPGProperty::SetMaxLength() should be done a check whether to actually set a limit or not depending on the kind of editor used.
wxPropertyGridInterface::SetPropertyMaxLength() should be implemented on top of wxPGProperty::SetMaxLength() to proceed only if maximum length was actually set.
The code to handle events split into separate functions dedicated to handle the events of specific type is more readable than the code concentrated in one function handling all kinds of events.
Because changing the number of columns may change their total width from value greater than current client size to the value less than this size or vice versa we need to know this total width prior to determining wxProperyGrid scrolled view in order to account this actual width in the calculations.
The ScintillaWX::ModifyScrollBars method is used to ensure that the
horizontal and vertical scrollbars are constantly up to date. It
computes the needed max and page size for the scrollbars based on a
combination of input data and internal state variables, compares the
needed values with the scrollbar’s current max and page size, and
updates the scrollbars if there is a difference.
Because of the current logic used, the method will try to update the
scroll bars in two cases where no updates are necessary. First, if a
scrollbar is not visible (or if word wrapping is on for the horizontal
scrollbar), ModifyScrollBars currently tries to set the max to 0.
However on some platforms, such as windows, this call can fail and
result in the max actually being set to 1. Consequently subsequent calls
to ModifyScrollBars will assume the value should be 0 but detect the
scrollbar’s max as 1 and try to update the value again. To avoid this,
instead set the scrollbar’s page size to 1 more than the max.
The second case is only for the horizontal scrollbar. Currently, the
function updates the scrollbar whenever the position is not 0. There
doesn’t seem to be any reason for this check, and so it has simply been
removed.
Closes https://github.com/wxWidgets/wxWidgets/pull/1327
Don't use ExtFloodFill() to extend the custom background colour to the
edges as this results in weird problems due to an apparent bug in nVidia
drivers, see #18387.
Instead, just extend the rectangle passed to FillRect(), which doesn't
look quite as good under Windows 10, but is pretty close, and shouldn't
suffer from the nVidia bug while also slightly improving appearance
under Windows 7.
Closes https://github.com/wxWidgets/wxWidgets/pull/1319
If the kind of the bitmap/icon used by the control didn't change (which
will be most often the case, as using both an icon and a bitmap with the
same control is vanishingly rare), there is no need to update the window
style.
No real changes, this is just a micro-optimization.
DeleteCurrentHandleIfNeeded() is already called from Free() which is
unconditionally called at the beginning of the function, so there is no
need to call it again.
This is just a micro-optimization: there is no need to call
InvalidateBestSize() if the size of the bitmap doesn't actually change
(as will most often be the case when this method is called after the
control creation).
