Keep validation adornment visibility up to date

[grokys]

Fix for issue #242

The ShowValidateError method wasn't getting called to update the validation adorner when ValidationMessage.ShowError changes independent of a TextChanged or focus event.

I'm not sure if this should be done here or in the WhenAny above which updates ShowError - I've put it here as that's where the existing call to ShowValidateError is.

[grokys]

Actually, I'm not sure why the validation adornment is updated only on TextChanged/focus events. Wouldn't it make more sense to update it whenever ShowError changes (with a throttle)?

[shana]

@haacked @niik @shiftkey This is pretty much taken verbatim from the Desktop app iirc. Do you know of the rationale for the reason it's done this way by any chance (as per @grokys question)?

Maybe the desktop app has since changed this, I'll check.

[haacked]

I don't recall at all unfortunately. Maybe the others can remember.

[shiftkey]

@shana @grokys I'm also struggling to recall the context, but from memory listening to ShowError will cover where this value is set programmatically - one example is where we probe the Enterprise server - an asynchronous operation based to what the user has entered - but that doesn't seem like the behaviour that #242 is reporting.

The only place I can see subscribing to this is here (ValidatesControl is a TextBox but note that we don't subscribe to it's events):

this.WhenAny(x => x.ValidatesControl, x => x.Value)
    .WhereNotNull()
    .Select(control =>
        this.WhenAny(x => x.ShowError, x => x.Value)
            .DistinctUntilChanged()
            .SelectMany(showError =>
                Observable.Return(showError)
                    .Throttle(TimeSpan.FromSeconds(showError ? defaultTextChangeThrottle : TextChangeThrottle))))
    .Switch()
    .Subscribe(showError =>
    {
        IsShowingMessage = showError;
        Visibility = IsShowingMessage ? Visibility.Visible : Visibility.Hidden;
    });

Those two properties in the subscription are just dependency properties, nothing fancy there.

[shana]

Ok, so feels like we just need to make extra sure we don't regress anything.

@mponce1 When the testing for the next release happens, besides just testing for #242, could you also test other places where errors should show up in the login, clone, creation and publish dialogs. This fix affects all of them. Stuff like:

• Enterprise login with invalid url
• Enterprise login with valid url but not a valid enterprise instance
• Repository already exists remotely when trying to create
• ... etc