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.
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.
RegisterHotKey() wrongly expected to be given VK_XXX MSW virtual key
code constant, which couldn't work in portable code, so fix it to accept
WXK_XXX constants, while preserving compatibility by still accepting
VK_XXX values not clashing with them.
Add wxFileDialog::GetCurrentlySelectedFilterIndex() similar to the
existing GetCurrentlySelectedFilename(), which can be used to retrieve
the index of the currently selected filter and update the state of the
extra controls in wxFileDialog accordingly.
Implement this for wxMSW only by updating the internally stored value
from the native CDN_TYPECHANGE notification and also generating a
wxEVT_UPDATE_UI event to allow the extra controls to update themselves.
Closes https://github.com/wxWidgets/wxWidgets/pull/1310
Describe what is returned when corresponding functions are queried for values of built-in attributes and wxPG_EX_WRITEONLY_BUILTIN_ATTRIBUTES style is set.
This attribute is used only internally in wxArrayStringProperty and thus 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.
This attribute is used only to set internal data member in wxArrayStringProperty and thus can be considered as a built-in attribute which doesn't have to be stored in the property's attribute store.
Both attributes are used only in wxBoolProperty and wxFlagsProperty to set respective internal flags and don't have to be stored in the property's attribute store.
wxPG_COLOUR_HAS_ALPHA attribute is used only in wxSystemColourProperty (and derived properties) to set respective internal flag so it doesn't have to be stored in the property's attribute store.
For built-in attributes (like wxPG_PROP_STRING_PASSWORD) wxPGProperty::DoSetAttribute() should return true to give the option (controlled by wxPG_EX_WRITEONLY_BUILTIN_ATTRIBUTES style) to prevent the attribute from being stored into property's attribute storage.
Provide a way to retrieve the name of the current system appearance
(mostly for diagnostic purposes) and check if it uses predominantly dark
colours.
Currently this class has a non-trivial (but still very simple)
implementation under macOS only and simply checks whether the default
text colour is brighter than the default background colour under the
other platforms, but other platform-specific implementations could be
added later.
Also update the drawing sample "system colours" page to show the system
appearance as well.
Send events from generic wxColourPickerCtrl when the currently selected
colour in the dialog shown by it changes and when this dialog is
cancelled.
Notice that currently this only works on wxMSW as it relies on
wxEVT_COLOUR_CHANGED support in wxColourDialog which is only available
there.
Based on work of Trylz, see https://github.com/wxWidgets/wxWidgets/pull/1219
Add support for a new event sent by wxColourDialog, currently only under
MSW, when the colour currently selected in it changes.
Based on work by Trylz, see https://github.com/wxWidgets/wxWidgets/pull/1219
For some reason, 7f10d1fa8a handled
wxSYS_CARET_ON_MSEC and wxSYS_CARET_OFF_MSEC differently in wxGTK, even
though it looks like they should be handled in exactly the same way.
Change the code to do this, which results in returning 0 for the former
setting if the caret doesn't blink at all, just as was already the case
for the latter one.
See https://github.com/wxWidgets/wxWidgets/pull/1285
See #17629.
The documentation stated that (a) wxSYS_CARET_{ON|OFF}_MSEC settings
were not supported on MSW and (b) if a setting was not supported a
negative value was returned. However, when calling
wxSystemSettings::GetMetric(wxSYS_CARET_{ON|OFF}_MSEC), not only the
method asserted but 0 was returned instead of a negative value.
Fix this by using the value returned by ::GetCaretBlinkTime() for
wxSYS_CARET_{ON|OFF}_MSEC.
The documentation for wxSYS_CARET_TIMEOUT_MSEC does not list any
platform limitations; however, attempting to obtain this value resulted
in an assert and 0 returned. Fix this by returning -1. Returning -1 may
not the be the ideal solution, but there is no value reserved for the
setting not being supported and the caret on MSW usually blinks.
Closes https://github.com/wxWidgets/wxWidgets/pull/1285
This removes irregular behaviour in setting the label of a control. Creating
a control with label now behaves the same as setting or changing the label
later on. And behaves the same as for other tools in the wxToolBar.
Closes https://github.com/wxWidgets/wxWidgets/pull/1289
In InsertColumn(long, const wxListItem&) a line was split inside a
referred overloaded method signature which prevented doxygen to
recognize and link the referred method.
In InsertColumn(long, const wxString&, int, int) non-existing
Insert(long, const wxListItem&) overload was referenced instead of
InsertColumn(long, const wxListItem&).
Clsoes https://github.com/wxWidgets/wxWidgets/pull/1279
Resetting the insertion point position to 0 after calling
wxTextCtrl::SetValue() or ChangeValue() which didn't really change the
control contents was unexpected, as such calls are supposed to be
"optimized away", and this was indeed the case under wxMSW and wxOSX,
but not in wxGTK.
So change wxGTK to follow the other ports, add a unit test checking for
this behaviour and officially document it.
As a side effect, this ensures that the numeric validator classes don't
reset the insertion point position to 0 on every focus loss under wxGTK,
as happened before.
