I’ve got a fairly common situation in my Silverlight UI where the Visibility of various elements is bound to some property on the ViewModel. For instance, I may have a control like this:
<myapp:WarningView Visibility="{Binding IsInWarningState}" />
If the warning state is true, we want to show the control, if not, we don’t. The problem is that I’ve got many situations where the page renders and displays all the content, including the WarningView control, and then a second later hides the view, which looks really clumsy.
I think what’s happening is that the View loads and makes an async call to the server to get the data, but until that happens, there’s no DataContext and so nothing for the WarningView to bind to, and uses defaults, and the default is to show the control.
It seems cleanest for the view to instantiate its own view model, or at least that’s what I’m doing now. And since the call is async, there could always be some interval when you want to be showing something but you don’t have the real data to show yet. I could imagine making a mock ViewModel with better defaults, but that seems like a lot of work to do project wide.
So what’s the best way around this problem?
Well, long after I gave up on this, I stumbled across the answer myself: in the binding you can specify a FallbackValue and/or TargetNullValue, which specify a value to use when the thing you’re binding to can’t be obtained or is null. My problem was that the View loads and creates the ViewModel, and for the instant between when the View is visible and when the binding is complete, the controls are visible, and then the binding collapses them, and this causes the flicker. By setting Fallback values, I can make sure that the controls are Collapsed, and then turn on only when bound, and then they stay on. No flicker.