I updated to the service pack, and received a warning about an obsolete reference on the following line of code
The message is that
'Telerik.Windows.Controls.Data.PropertyGrid.PropertyGridFieldEventArgs' is obsolete: 'This type is marked as obsolete. Please, use Telerik.Windows.Controls.SelectionChanged instead'.
Only when I switch to Telerik.Windows.Controls.SelectionChanged, it's not recognized. Is this a bug, or am I missing a reference. (I already have Telerik.Windows.Controls referenced in the project.)
Private Sub RadPropertyGrid1_SelectedFieldChanged(sender As System.Object, e As Telerik.Windows.Controls.Data.PropertyGrid.PropertyGridFieldEventArgs) Handles RadPropertyGrid1.SelectedFieldChangedThe message is that
'Telerik.Windows.Controls.Data.PropertyGrid.PropertyGridFieldEventArgs' is obsolete: 'This type is marked as obsolete. Please, use Telerik.Windows.Controls.SelectionChanged instead'.
Only when I switch to Telerik.Windows.Controls.SelectionChanged, it's not recognized. Is this a bug, or am I missing a reference. (I already have Telerik.Windows.Controls referenced in the project.)
3 Answers, 1 is accepted
0
Accepted
Hello,
Vera
the Telerik team
This event and SelectedField property were obsolete with Q1 2013. You can use PropertyGrid.SelectionChanged event and SelectedPropertyDefinition property instead.
Let us know if you experience any problems.
Vera
the Telerik team
Explore the entire Telerik portfolio by downloading Telerik DevCraft Ultimate.
0
Noel
Top achievements
Rank 1
Rank 1
answered on 23 Jul 2015, 09:09 PM
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
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
0
Hello,
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
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