Fix bug introduced by the (relatively) recent wxJoystick rewrite: using
"!m_buttons" is wrong as it always returns 0 for any button(s) but the
first one, we need bit-wise "~m_buttons" here instead.
See https://github.com/wxWidgets/wxWidgets/pull/942
See #1142.
Don't assume that m_findIter is always valid initially, i.e. after
FindFirst() is called, as this is not the case if the memory FS is
empty, i.e. which no files had been added to it yet.
This also allows to simplify the iteration logic, as we don't need to
check m_findArgument (which, in turn, obviates the need to clear it when
we reach the end of the iteration) and can just use m_findIter directly.
Closes#18416.
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.
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).
wxStaticBitmap tried to automatically resize itself to its new size, but
did it wrongly (since what looks like ever, or at least since the first
version in the VCS, which is 2bda0e1738,
from 21 years ago) because it assumed that the size of wxStaticBitmap
window is the same as the size of the bitmap it is showing, which is not
the case when it uses border style such as wxBORDER_RAISED.
Fix this by resizing it to the current size adjusted by the difference
between the old and new bitmap sizes. Alternative approach would be to
just use SetSize(GetBestSize()), as the other ports do, but keep the
changes to the minimum for now.
Closes#18398.
Calling Flush() is supposed to make everything drawn so far immediately
visible, which means propagating it to the wxImage being drawn on in the
case of image-based graphics context, but wxMacCoreGraphicsImageContext
didn't do it, unlike Cairo and GDI+ version.
Fix this by overriding Flush() in it to explicitly update m_image.
Closes https://github.com/wxWidgets/wxWidgets/pull/1321
Call FormatMessage with the IGNORE_INSERTS flag. Without the flag,
the FormatMessage() call will fail when the error message contains
inserts (such as %1), as we are not providing any arguments.
Various Windows system error messages contain inserts; e.g. error 193.
See also: https://devblogs.microsoft.com/oldnewthing/20071128-00/?p=24353
So far it was implemented as property which could take int values 0/1 so it was acting essentially as a Boolean property. Implementing it explicitly as a Boolean one will make it more intuitive. Legacy code setting 0/1 int values shouldn't be affected because conversion from int to bool is implicit.
All wxPG_FILE_xxx attributes are used only in wxFileProperty to set respective internal data members and don't have to be stored in the property's attribute store.
By moving the code to display file selector dialog from wxPGFileDialogAdapter to wxFileProperty we can encapsulate the operation of showing the dialog because all required parameters are stored in the corresponding data members and there is no need to use call generic GetAttribute() function to retrieve them. This also helps in making wxFileProperty attributes built-ones in the future.
This attribute is used only internally in wxFileProperty so it can be considered as a built-in attribute which value can be stored in the local data member and not in the property's attribute store.
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.
