Move template function NumericValidation() to wxNumericProperty because all data necessary to validate the value are available here: acceptable value range, SpinCtrl editor value wrapping mode, etc.
All numeric properties (wxIntProperty, wxUIntProperty, wxFloatProperty) share some features (like specific attributes, numeric validation, SpinCtrl editor support) so for the sake of clear design it would be good to derive them from the common base class (wxNumericProperty) in which all shared functions are implemented. This class is not intended to be instantiated so it's an abstract class.
Instantiate NumericValidation() template directly for required data type in DoValidation() and avoid this way intermediate conversions to another data types.
Duplicating the code of the entire NumericValidation() template function just for one specialization (for double value type) seems to be an overkill. Only small fraction of the code (to round the validated value) is really dependent on the value type and this part can be moved to the template function GetRoundedValue() which in turn can be specialized as required.
Use wxWindow instead of wxControl in wxGridCellEditor to allow using
any window as an editor control, as it doesn't need to be a wxControl.
Closes https://github.com/wxWidgets/wxWidgets/pull/1370
This OS update has broken resizing of NSOpenGLView, which worked
correctly up until to 10.14.4.
Work around it by preventing the default implementation of update from
being executed. It's not clear why should it help with the problem, but
it does.
Closes https://github.com/wxWidgets/wxWidgets/pull/1354Closes#18402.
The last digit was truncated as the code discarded the trailing "\n"
which wasn't really there, as ReadLine() helper function already removed
it, and so ended up removing the last digit of the line number,
resulting in mostly plausibly looking but completely wrong line
information in the assert dialog.
This was already done in the other functions, but not this one,
resulting in a crash if it was called for an object with null m_nowpeer
(e.g. before it's created or when it's not a real wxNonOwnedWindow
object as when it's a subobject of wxTDIChildFrame).
See #18423.
Under wxGTK, wxGauge was returning fixed values for height and width.
This meant that the gauge would not center correctly in a sizer,
particularly under GTK+ 3 where the default gauge height is just a few
pixels.
Following this change, wxGauge renders correctly on GTK+ 3 and matches
the reference widget display in the gtk3-widget-factory app.
Note, this change will also result in a slimmer widget on GTK+ 2, but
the gauge height can be forced using wxGauge::SetMinSize() on the older
toolkit.
The gauge presentation is totally theme dependent under GTK+ 3. For
example, the user can have thicker gauges by setting the following in
their ~/.config/gtk-3.0/gtk.css file:
progress, trough {
min-height: 20px;
}
Closes https://github.com/wxWidgets/wxWidgets/pull/1353
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.
Combination of multiple borders looks bad, so skip drawing the left/top
borders in wxGrid{Row,Col,Corner}LabelWindow if wxGrid already has a
border around it.
Grid contents was drawn in grey colour instead of the usual active one
when it was disabled, but the row and column labels kept their default
appearance, which looked out of place.
Fix this by greying them out too. This should have been arguably done in
73145b0ed1 ~17 years ago, but better late
than never.
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.
Make QTreeWidgetItems editable and add SelectedClicked as an edit trigger.
Simplify closing the editor as QAbstractItemView already connects to its delegate closeEditor signal.
Ensure that wxTreeItemData is deleted.
Use a QT delegate to create editor and perform custom model update.
Connect to the closeEditor signal to send out end label edit events and decide whether to accept changes.
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.
