Calls to StandardValues in PropertyDataAccessor

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.

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

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.

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

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

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.

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