Support for RefreshPropertiesAttribute

Hi Greg,

You are correct, the RefreshPropertiesAttribute is not currently supported. Since our PropertyGrid leverages WPF binding statements, property changes are immediately reflected in UI.

To support this, your underlying object must implement INotifyPropertyChanged, use dependency properties, or include a XYZChanged event for each non-dependency property (where XYZ is the property name). With this in place, changes will be automatically sync'ed when the property change notification is received.

Therefore, if you have three properties, say Height, Width, and Area (which is readonly and equals Height * Width). Then changes to the Height or Width would need to signal that Area has also changed.

Thanks for your help. Whilst your suggested methods will work fine for our tightly linked properties, they are less than ideal for some of our properties which change the visibility, the read-only status, etc of many other properties within the grid. Can you suggest any other methods which would be suitable for mass updates across the grid?

Thanks

Greg.

Hi Greg,

That is correct. I've added an item to our TODO list for RefreshPropertiesAttribute support.

If this is something you need right away, then you can contract for our time to implement it (http://www.actiprosoftware.com/Purchase/ConsultingServices.aspx).

This isn't urgent but would be very useful in the long run, could you give me an estimated ETA on when this could be implmented. Also could you suggest a way I could overcome this issue using the current system.

Thanks

Greg.

Hi Greg,

I can't give an ETA since this would need to be prioritized with everything else that is on the TODO lists for our products. We do plan on focusing on the TODO lists after we get WPF Studio 5.0 out.

The most direct way would be to call PropertyGrid.Refresh, but this would required that you add some special hooks to know when that needs to be done.

Probably the best method would be to build a custom factory and data accessor. This is just off the top of my head, but you would need to:

First, create a class that implements from IPropertyDataAccessor, say MyPropertyDataAccessor, which will take a IPropertyDataAccessor as a parameter to it's constructor. MyPropertyDataAccessor would act as a wrapper, and would mostly pipe the interface members directly to the wrapped IPropertyDataAccessor. Then in the Value/Values property set methods, you could determine if the RefreshPropertiesAttribute is defined (with an appropriate value) and call Refresh on the IPropertyDataAccessor.Parent element, if any.

Second, you would need to create a class that dervies from TypeDescriptorFactory (or TypeReflectionFactory). Your class would override GetProperties(object[], DataFactoryOptions), and wrap each of the return properties with an instance of MyPropertyDataAccessor.

If the Refresh method doesn't work, then you could hook up an event on the custom data factory that could be used to refresh the PropertyGrid. You would probably have to do this for root properties anyway, since they do not have an IPropertyDataAccessor.Parent.

If you run into issues, send over a sample project to our support address and we can take a look.

[Modified at 03/25/2009 01:03 PM]

Hi, this has really helped, only one problem though. The parent of the IPropertyDataAccessors refresh function does not update enough (or any as far as I can see) of the property grid, however the property grids refresh function does the refresh perfectly. I currently have access to the property grid through a nasty hack in my code which isn't suitable for anything but the demo app I am working with, is there a way I can get access to the property grid from the IPropertyDataAccessor (or any other means).

Thanks

Greg.

Hi Greg,

Unforutately, the data factory (a.k.a. data layer) is purposefully separate from the PropertyGrid (a.k.a. UI layer). So there is no direct way to access the PropertyGrid from the data factory or the accessors it generates.

One option is to include an event on your data factory, which you can then hook into when it's assigned to the PropertyGrid.DataFactory property. Your custom IPropertyDataAccessors would need to contain a reference to the data factory in order to raise the event. Then in the event handler you would refresh the PropertyGrid.

Another option would be to customize the UI layer, instead of the data layer as previously suggested. In this case, you would need to create a custom PropertyGrid and custom PropertyGridDataAccessorItem.

The custom PropertyGrwould override GetContainerForItemOverride and return an instance of your custom PropertyGridDataAccessorItem.

The custom PropertyGridDataAccessorItem would need to override OnPropertyChanged(PropertyChangedEventArgs) and look for changes to the Value/Values properties. When it detects a change, it can access the PropertyGrid via the logical parent and/or search up the visual tree.

Some things to note:

1. To access the PropertyDescriptor from the PropertyDataAccessorItem, you will need to cast this to a ITypeDescriptorContext (e.g. ((ITypeDescriptorContext)this).PropertyDescriptor).
2. Dynamic theme changing will not work out of the box for your derivations, due to how WPF works. If you send over an email to our support address we can provide a work around for this.

Hi,

Just noticed that version 5.0 (2009.1) of the studio is out and I was wondering if support for RefreshProperties had been included and if not may it now be coming in the forseeable future?

Thanks,
Greg.

Hi Greg,

This has not be implemented yet, nor has it be scoped for a release yet. So I can't say for sure yet. I will post again when we know if this will make it into the next release.

Hi
I'd like to add my vote to getting support for this attribute in please.

Many Thanks.

Best regards

Marek

Hi Marek,

Thanks, we'll update this forum thread when support is added so you will also be notified.

Hi,

is the RefreshPropertiesAttribute supported by the current version? I could not find any usage of it in your PropertyGrid samples.

Best regards

Sonja

Hi Sonja,

Sorry but no, we still don't currently support RefreshPropertiesAttribute.  This info in the first reply of this thread still applies:

Your underlying object must implement INotifyPropertyChanged, use dependency properties, or include a XYZChanged event for each non-dependency property (where XYZ is the property name). With this in place, changes will be automatically sync'ed when the property change notification is received.

Thus in WPF, you generally don't need a RefreshPropertiesAttribute if your data object is set up with those things in mind.  

If you have a specific need for it, what would be best is if you could put together a new simple sample project that shows the scenario and we can debug with that to see if adding in support for the attribute would be feasible.  If you do send a sample project to our support address, please remove the bin/obj folders from the ZIP and rename the .zip file extension so it doesn't get spam blocked.  Thanks!

Hi,

I have the same problem as discribed by Greg in his second post. We have several properties which change the visibility, the readonly state ect. depending on the value of another property. We had hoped to reuse our previous algorithm, which determines the browsable and read-only values ​​when building the Property-Descriptors.

I have already found your solution for dynamic read-only values in the PropertyGrid examples. But due to the fact that the Property-Descriptors are not exchanged, our previous algorithm is no longer usable.

We hoped that there would be an implementation of the RefreshPropertiesAttribute nine years after the first request. Is there another way to achieve a refresh of the Property-Descriptors? PropertyGrid.Refresh is not sufficient, because we use PropertyChanged as UpdateSourceTrigger for some properties and the property-textboxes looses focus when calling the Refresh-method.

Kind regards,

Sonja

Hi Sonja,

That there is part of the problem we haven't done this.... since any kind of referesh functionality we make would likely wipe out and re-create the property editors.  Then you lose scroll, selection, and focus states. 

The one idea I did have now was to run through all the property models and perhaps raise each of their INotifyPropertyChanged.PropertyChanged events for properties like "Value", "ValueAsString", "IsReadOnly", etc.  Since if those get raised, the property editor UI elements should rebind themselves.  That might effectively be like a "repaint" of the property grid.

You could give that a try, or if you would like us to look into it, please send over a new simple sample project like I requested above.  Thanks!