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.
We need implement copy ctor and assignment operator because we are going to do a shallow copy of wxPGHashMapS2P data member and therefore we have to manually update reference counters of the objects being referenced in this map.
Notification about changes of column widths needs to be sent locally from wxPropertyGrid to wxPropertyGridManager (to update the header) so it would be good to use a dedicated non-public event type for these purposes.
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.
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.
OnValidationFailure() in derived class wxEnumProperty has the same implementation (empty body) as the implementation in the base class wxPGProperty so overriding this function in derived class is not necessary.
wxPropertyGridHeader associated with wxPropertyGrid has to be notified about every horizontal scroll of the grid.
New position is sent with dedicated wxEVT_PG_HSCROLL event being handled by wxPropertyGridManager which in turn scrolls the header accordingly.
See #18313.
New method of calculating of the new position/size of the editor (introduced in 95461c566d) doesn't work well in all cases so we have to go back to the (modified) old method. To get the correct position of the editor cell from the absolute position of the splitter 0 we have to shift it by the origin of the scrolled view area.
See #18313.
This basically removes the "adv" library, even though it's still
preserved for compatibility with user make/project files referring to
it.
It is done because the distinction between "adv" and "core" was never
really clear (e.g. why wxTreeCtrl was in core but wxTreeListCtrl in
adv?) and it prevented some core classes from using adv ones.
When extra style bits are set with the call to
wxPropertyGridManager::SetExtraStyle(), only those which are relevant
to wxPropertyGrid should be passed to the underlying property grid object.
Because it can happen that not all extra style bits of the underlying
wxPropertyGrid have been effectively changed by call to SetExtraStyle()
(e.g. wxPG_EX_NATIVE_DOUBLE_BUFFERING), we have to get the actual style
bits prior to storing them.
When there is open an editor for some property and in the same time
wxPropertyGrid layout is changed (due to the adding or removing a property,
sorting), it is necessary to recalculate the actual position of the active
editor to display it in the cell dedicated for the edited property. Under
some platforms the position of the edit control is shifted within the cell
and we have to take this shift into account in repositioning process.
Because actual value of the shift depends on the platform and on
the particular control, it is convenient to determine actual shift when
the editor is created and use this value whenever repositioning is done.
Close#17912.
