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.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
at the same position as the text which is displayed as a property value
prior to the editing.
Position of the editor associated with properties like StringProperty,
IntProperty, etc. needs to be adjusted in order to display edited text
string at the same position as the text which is displayed as a property
value prior to the editing.
When entered wxFloatProperty, wxIntProperty or wxUIntProperty is out of range then there is displayed a warning message presenting a valid range. Instead of displaying in this message numeric values in default (and fixed) format we should display values which are formatted based on to the current attributes of the property (like wxPG_UINT_PREFIX, wxPG_UINT_BASE, wxPG_FLOAT_PRECISION).
To do so, we shouldn't format respective values on our own in NumericValidation() but instead call wxPGProperty()::ValueToString() which returns value string formatted in line with attributes.
Closes#17601
Because on some ports native renderers require a valid reference to the windows be drawn then it is necessary to implement and use new wxPGCellRenderer::DrawCaptionSelectionRect method which passes this additional argument.
SetPropertyTextColour, SetPropertyBackgroundColour methods are able to set colours recursively for sub-properties but SetPropertyColoursToDefault method is not.
For the sake of consistency, SetPropertyColoursToDefault method is extended to have the same capabilities as SetPropertyTextColour and SetPropertyBackgroundColour. Behaviour and signature in default case (no recursion) is preserved.
For internal purposes there were also implemented helper methods in wxPGProperty class: SetDefaultColours, ClearCells.
