wxUIntProperty::DoValidation() is already declared as private and the same access level should be applied to DoValidation() in other numeric properties because these functions are helpers intended for internal use only.
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.
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 notably fixes the problem with wxAuiMDIChildFrame::GetScreenRect()
returning the wrong window position since the changes of
c1bcf16eb9.
Closes#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
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.
Using "!(cond)" inside wxASSERT macro expansion prevented both gcc and
clang (although not MSVC) from giving -Wparentheses warnings if the
assignment operator was accidentally used instead of the equality
comparison operator.
Change the macro definition to use the condition directly, without
negating it, to let gcc/clang give the warning if appropriate.
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.
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.
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.
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.
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.
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.
