We think, EnabledIf attribute have UI refresh issue

Technical
22

Thanks @justin_c_i for the workaround! I see that you’re manually updating the dependent property. But why add the delay? And is there another reason other than not blocking the UI thread to run it asynchronously?

23

It should be on different thread, So I added the Task.Run and I added delay because OpenTap Updation will be in process , So I added a delay then we update the property manually,

Did this work around worked for you?

Note: This all are my assumptions.

24

It did not work for me, unfortunately. Thanks anyway!

@brennen_direnzo is the OpenTAP UserDialog intended to update the UI based on the PropertyChangedEventHandler? I think we’re all making that assumption, but is it true?

25

We will probably need @rolf_madsen to answer that. I’m not sure.

26

I figured out the answer!

I dug into the source and there’s a static method in the UserInput class called NotifyChanged.

/// <summary> Call to notify the user interface that an object property has changed. </summary>
/// <param name="obj"></param>
/// <param name="property"></param>
public static void NotifyChanged(object obj, string property)
{
    userInterface?.NotifyChanged(obj, property);
}

The UserInput class is basically a static class, in that it has all static properties, members, and methods (so it’s all but a static class). Anyway, the advantage is you can always refer to the current UserInput being displayed, and thus notify the UserInput dialog (if you’re using the Editor) of a property changing.

The easy way to implement this is keep your OnPropertyChanged method that invokes your INotifyPropertyChanged.PropertyChanged event handler, but add inside that method this UserInput.NotifyChanged method, like this:

        public void OnPropertyChanged([CallerMemberName] string propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
            UserInput.NotifyChanged(this, propertyName);
        }

This will even cascade the Property dependencies! So if you have Property A with an EnabledIf attribute that’s dependent on Property B, calling OnPropertyChanged() (and thus UserInput.NotifyChanged()) in the Property B setter will cascade down to Property A, so you only have to call OnPropertyChanged() for Property B. Cool right? So this all allows you to keep the same MVVM scheme you usually would with WPF.

Now @justin_c_i you don’t need the workaround anymore. No more updating on a separate thread, just use this!

2 Likes