Noel

I know this was posted a long time ago, but I just ran across a scenario
where deprecating the PropertyGridField.IsSelectedChanged actually will end up
in potentially more wasted cycles under specific circumstances for our code
base. We use EditorAttribute assignment in many places and many of our
property editor controls are more complicated than just a simple direct 1:1
translation/editor. As such, we can have many various controls within
each property editor assigned via the EditorAttribute property and most have
transparent backgrounds in order to keep everything within the currently
selected theme. Why this becomes an issue is when you select a
PropertyGridField the assigned property editor control for the property in question
is highlighted and so any sub-controls like TextBlocks, or the like, within the
property editor control become hard to see due to the highlight of the
PropertyGridField. As well, just changing
the color of the highlight still yields similar issues.
Now, we did have a way to come up with a default set of colors for things
like TextBlocks (normal vs highlight), which would apply depending upon the
PropertyGridField selection state. I just recently got around to looking
at migrating this to the above suggested way and it turns out that
PropertyGrid.SelectionChanged event returns PropertyDefinitions and not PropertyGridFields
added or removed to the selected list. Since the only way to link this to
the proper property grid field in question is via the PropertyDefinition
DisplayName or SourceProperty.Name and doing string comparisons to *both* what
is added or removed collections. In addition, now every editor control
that needs to know if it is highlighted or not must hook into the
ParentPropertyGrid's SelectionChanged event and so instead of one editor's
PropertyGridField parent control firing an IsSelectedChanged event for that one
editor control we will have every visible and active editor control parsing
through the list of what is added or removed and doing string comparisons to
determine if the property it is currently assigned to is in the added or
removed collections…the processing cycles for this in very populated entities
with many specialized editor controls ends up being exponentially worse than a
single event specific to the field being selected. Which, I have to assume that the container
field has to fire some form of event to notify the property grid it is selected…so
I am curious why this type of functionality would be under consideration to be
removed?
To make matters a bit more complicated, we programmatically generate many of
our editor controls and some editor controls programmatically generate
"sub-controls", as such the XAML based styling path to handle this
would require a major over-haul of this particular aspect of our code base and
associated editor control data files.
So with this said I have two basic questions:
1.)Is there any way to easily cull down the major expense of having to hook into the primary parent property grid's selection changed event for every property editor control currently active?
2.)If not, upon removing the PropertyGridField.IsSelectedChanged functionality could you add either an alternate event that returns the PropertyGridFields as opposed to PropertyDefinitions =or= could you simply set a global value within the parent PropertyGrid that is the current PropertyGridField selected (I noticed this will be deprecated as well)?
Otherwise, I fear we will have to stop our telerik updates with which ever
version removes this functionality from the libraries...unfortunately...of
course there obviously very well could be some other way to approach this or
perhaps telerik plans to implement a new type of PropertyGridField in place of
the current PropertyGridField and thus why the deprecation of most anything
PropertyGridField related?
Any feedback on when this will be removed as well as the above
concerns/questions would be greatly appreciated!
Cheers,
-Noel

Ivan Ivanov

Can you please confirm whether you are using Flat render mode, or the virtualization mode (IsVirtualizing=True)? If so, you can get the root ItemsControl that displays the fields and access its container generator. With ContainerGenerator.GetContainerForItem(propertyDefinition) you can access the respective field. This should be a relatively fast operation and you will not have to cycle through all of the fields to find the one that you need.

Regards,
Ivan Ivanov
Telerik

Do you want to have your say when we set our development plans?
Do you want to know when a feature you care about is added or when a bug fixed?
Explore the
Telerik Feedback Portal
and vote to affect the priority of the items

Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.