This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have a class where the type of one property (henceforth “value property”) is dependent on the value of another property (henceforth “controlling property”). When I set the value of the controlling property the grid is not updating the type of the value properties until I collapse or expand the property. This fails when I set the controlling property to a None value which sets the value property to null thus removing the +/- for the item. All of my types are implementing the IPropertyNotifyChanged interface & setting the controlling property raises the event on both the controlling & the value property.
Here’s some pseudo code: class Bar : IData {...} class Baz : IData {...} class Foo : IPropertyNotifyChanged { public EValueType enum ControllingProp { get {…} set { switch( value ) { case Bar: this.ValueProp = new Bar(); case Baz: this.ValueProp = new Baz(); case None: this.ValueProp = null; } PropertyChanged(this, "ValueProp"); PropertyChanged(this, "ControllingProp"); } } public IData ValueProp { get; private set; } } When I change the value of ControllingProp prop the ValueProp’s type is changes accordingly and the events are raised. However the property Grid is not updating. Any suggestions? |
|
|
No one has any ideas why changing ControllingProp in the property grid does not cause the display for ValueProp to be updated? I'm evaluating this for a possible site license for my team but this issue is a critical one to solve. |
|
|
Sorry for the delay Mike and thank you for your reminder email. We have managed to reproduce the issue you're seeing and are looking into it now. We'll update this thread as soon as we discover what's causing this issue. Kind regards, John-Daniel Trask |
|
|
Hi Mike, Just to update you, we have found a solution to the issue however we will need to do some work to how the validation handling works in order to support the resolution. We will not be able to have this completed before early next week in our nightly builds. I hope that time frame won't cause you issues. Kind regards, John-Daniel Trask |
|
|
Thank you for the quick response. I look forward to trying out the new version! |
|
|
Hello Mike, We now have a candidate fix for this and it will be included in nightly builds dated 24 Nov 2009 and above, available from about 1430 GMT. Please let us know if you run into any problems. Sorry this took a bit longer to turn around than expected -- unfortunately we've had some immovable external commitments during the last week. If you need us to extend the trial licence while you evaluate the fix, drop us a line via the contact form and we'll be happy to arrange something for you. |
|
|
I downloaded the most recent build and I'm still seeing the same behavior. |
|
|
Hmm, I guess our test code is not accurately replicating your scenario. Could you provide us with a small but complete sample project that exhibits the problem? You can attach a zip file via the Options tab. Thanks! |
|
|
Here's the sample, The expected behavior is changing the Process It would be expected that DynamicData is updated with the new type, but it's not. |
|
|
Okay, this is occurring because the DynamicData property is read-only (as far as the public interface is concerned). The grid assumes that read-only properties are not going to change, and therefore does not monitor for changes to the subproperties. This assumption is invalid because of course read-only properties can change for "behind the scenes" reasons as they do in your case. I'll try to get this fixed for the next nightly. In the meantime, removing the "private" from the DynamicData setter should work around the problem -- let us know if you still see issues. Thanks for reporting this and for helping us track it down! |
|
|
That fixed it. In the planned usage we will have a mix of public & non-public setters. But I can proceed with my evaluation now. Thanks! |
|
|
Just to confirm, the next nightly (26 Nov) will contain the fix for non-public setters, so this issue shouldn't arise in your real implementation. |
|