Calls to StandardValues in PropertyDataAccessor

Grids for WPF Forum

Posted 7 years ago by Rick Edwards - UK
Version: 11.2.0553
Avatar

Hi all,

I basically have two applications that display an enum property in the PropertyGrid. The applications use exactly the same code to display the grid and set the selected object and so on. We have extended the Grid to use a custom data factory which creates custom data property accessors and again this code is identical between the two applications. The property to be displayed is an enumerated type and we are using a ComboBoxPropertyEditor to display a drop down list of selections that represent the underlying enum types. We do this through a Custom list type converter that's set as an attribute on the property. Again all this code is identical between the two applications.

Now in one application the drop down list is populated with the correct strings and the correct value selected to represent the underlying property value. However in the second application it isn't and we get no string values displayed in the drop down list. Through debugging the code it would appear that in the first application we call the StandardValues method in the CustomDataPropertyAccessor ok which goes on to call GetStandardValuesSupported in the list type converter correctly and the list is populated. In the second application the StandardValues method is not called and so the list gets nothing to display.

From what I can tell there is no difference in the code with regards to displaying the object and the property so can you tell me what dictates whether the StandardsValues method gets called or not? In both applications the data factory is creating the correct data accessors and they both have the list type converter set and the correct enum type and value. Is there some caching or refresh issue going on? 

Unfortunately I'm not able to send any example code at this time.

Any pointers would be good as we're a little stumped!

Rick Edwards

Comments (7)

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Rick,

If you are using the ComboBoxPropertyEditor, then ultimately ComboBox.ItemsSource is bound to IPropertyDataAccessor.StandardValues. This is not changed for that editor, but the ComboBox may be hidden if the property is read-only.

Anything that derives from CachedPropertyDataAccessorBase will cache their properties, so we don't make multiple calls into the associated PropertyDescriptor or TypeConverter. But unless you are dynamically changing a properties standard values during runtime and while it's being displayed then this wouldn't be a problem.

I'd recommend comparing the results of the DataFactory between the two applications. Making sure to drill into the PropertyDescriptors and checking TypeConverters. You can also simplify your application until the issue goes away, or you are down to a basic sample.


Actipro Software Support

Posted 7 years ago by Rick Edwards - UK
Avatar

Hi,

thanks for the reply, having done a little digging into the IPropertyDataAccessors create by the DataFactory it appears the only difference between the working application and the non-working application is the ValueTemplateKey. For the working app this is correctly set to be the following

ValueTemplateKey {TargetType=ActiproSoftware.Windows.Controls.PropertyGrid.PropertyGrid ID=ComboBoxValueTemplate} object {System.Windows.ComponentResourceKey}

Whereas in the failing app this is set to:

ValueTemplateKey null object

So I guess the next question is why in one instance is it getting the correct value template and not in the other?

Any ideas?

Rick

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Rick,

Assuming that your accessors are actually instances of PropertyDescriptorDataAccessor, then the ValueTemplateKey is pulled from the EditorAttribute associated with the property. So in the non-working case, either there is no EditorAttribute with a base type of PropertyEditor or the editor returns null from it's ValueTemplateKey.

It is normal for those to return null (but maybe not in your case), as that is only returning the property editor defined using an EditorAttribute. We have other areas where you can map editors (such as PropertyGrid.PropertyEditors and BuiltinEditors.PropertyEditors) based on the property's name/type and/or it's object type.


Actipro Software Support

Posted 7 years ago by Rick Edwards - UK
Avatar

Hi,

in response to the above both our applications are pointing to the same object with the same property and the same custom editor attribute, in one the attribute is being picked up and the ValueTemplateKey set correctly, in the other it isn't and the key is null. If I hack the data property accessor to return the correct ComponentResourceKey as the ValueTemplateKey then the drop down works as it should.

Now the only difference in our applications is one is a WPF application that launches a WPF dialogue and the other is a legacy MFC application that launches a WPF dialogue. Interestingly the application that fails is the WPF application, the MFC works as it should though we also see the problem when we launch the dialogue through a test Console app in the MFC project. Note that both applications are using exactly the same code to create and display the WPF dialogue containing the PropertyGrid and are reflecting over exactly the same object with the same property editor attribute.

The only thing I can now think of is we have a difference in the loading of the Actipro dll's at startup which means the property grid in the WPF application is not picking up the property editor attribute when it should. Either that or it's a resource issue and the component resource key with id ComboBoxValueTemplate is not being set.

We add the extended Property grid editor suite through a resource dictionary using the propgrid:PropertyEditorsModifier and propgrid:PropertyEditorsModifierActionAdd elements but the ComboBoxPropertyEditor I assume is a built in type and isn't added in this way?

Unfortunately this has us scratching our heads here.

Rick

Posted 7 years ago by Rick Edwards - UK
Avatar

Following up, analysis of the dll's loaded shows a difference, the working app loads the ActiproSoftware.Shared.Wpf351.dll before loading the ActiproSoftware.Editors.Wpf351.dll whereas the broken app loads the shared dll after loading the editors, I'm thinking this is probably an issue.

Cheers

Rick

[Modified 7 years ago]

Posted 7 years ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Rick,

The code for ValueTemplateKey is effectively (where this is the PropertyDescriptorDataAccessor):

var editor = this.PropertyDescriptor.GetEditor(typeof(PropertyEditor)) as PropertyEditor;
return (editor != null) ? editor.ValueTemplateKey : null;

I would suspect that the PropertyDescriptor is not returning an appropriate PropertyEditor, but you should be able to verify that. If that's the case, then I'm not sure there is much we can do, as we are dependent on the .NET PropertyDescriptor in that case.

The PropertyGrid assembly references the Shared Library, so I'd be surprised if you can load and display the PropertyGrid without it being loaded. You may try explicitly loading the Shared Library then the PropertyGrid and see if that fixes your issue. I would also make sure that your application references the Shared Library as well as the PropertyGrid assembly.


Actipro Software Support

Answer - Posted 7 years ago by Rick Edwards - UK
Avatar

Hi,

finally got to the bottom of this. Turns out the application that worked had the Actipro dll's in the local output folders of Visual Studio (Debug, Release, etc) whereas the the application that failed didn't. One assumes the reason the PropertyGrid was still working was because the Actipro dll's had been previously installed in the GAC. Without the local dll's the PropertyEditor attribute wasn't being recognised so was returning null for the ValueTemplate. Strange that the issue was only really manifested in the ComboBoxEditor hence the difficulty in debugging!

Anyway fixed now, thanks for all your help.

Regards

Rick Edwards

The latest build of this product (v2019.1 build 0681) was released 9 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.