Syncronous ProgressBar status updates

Within our application we make calls to server services both synchronously and asynchronously. There are some service calls that we want to make synchronously and still be able to show the progress bar if the process is lengthy. The existing progress bar was on the UI thread and therefore never updated until the service call completed. Martin has upgraded the progress bar to overcome this limitation.

Within each DocumentViewModel, there is an internal reference counter (held in the AbstractDocumentViewModel) which keeps track of how many things are currently in progress for that document.
When this counter > 0, the progress bar (or spinning busy graphic) is shown on that document.

In order to notify it that something is in progress (usually a service call or something which will take a detectable period of time to complete), within your DocumentViewModel class, you can call :

ProgressBarToggle(true);

And to notify that this action is finished with :

ProgressBarToggle(false);

The method ProgressBarToggle, is threadsafe and may be called on any thread. If it is called on the UI thread in direct response to a UI event such as a button click, then the method will take care of the fact that the UI would normally not update the progress bar visibility until the event handling method was complete & fork the thread to handle outstanding UI messages and binding updates, before continuing on with the functionality of the event handling method. In effect a VB-style “DoEvents” under the covers.

[Note : This has been added to the fledgling developer document in sharepoint :
.../Leisureflexdotnet/Design%2Documents/Forms/AllItems.aspx/“Sandstorm Developer Notes Braindump.docx”]

WCF Fault Exception

Martin had an obscure problem with WCF on our Fitspace / Fitness First Widget.

This article describes a similar issue Obscure WCF Exception mislaid blame

Databinding and Nullable Types

In this article (Using WPF Binding StringFormat property with nullable types) Karl Shifflett describes how to bind to properties that have a nullable type.

In summary, use TargetNullValue property of the binding like this:

<TextBox
Text="{Binding Path=NumberOfComputers,
TargetNullValue={x:Static sys:String.Empty},
StringFormat=\{0:D\}}" />

TargetNullValue requires .NET 3.5 Framework Service Pack 1. Previously this would have required a IValueConverter class to deal with the Null values.

Sorting Arrays

Martin pointed me at this interesting blog regarding Array.Sort Sorting Arrays

I used Array.Sort previously in this post Sorting and De-Duping Arrays but didn't investigate further at that time.

A quick look at Array.Sort(...) shows that it has 17 overloads and lots of things to try out at some point in the future.

Parameter Ordering

Although the two ComboBox samples below look very similar they actually function a little differently.
The first sample sets the selected item based on the SelectedItem binding and then almost instantaneously sets the SelectedItem based on the first record in the ItemsSource binding.

<ComboBox
DisplayMemberPath="Description"
SelectedItem="{Binding Path=EditedCourse.Centre, Mode=TwoWay}"
SSForm:FormItem.LabelContent="Centre"
IsEditable="{Binding Path=EditedCourse.IsCentreEditable}">
<ComboBox.ItemsSource>
<Binding
Mode="OneWay">
<Binding.Source>
<CollectionViewSource
x:Name="PART_CentresView"
Source="{Binding Source={StaticResource ViewModel}, Path=Centres, Mode=OneWay}" />
</Binding.Source>
</Binding>
</ComboBox.ItemsSource>
</ComboBox>

The second sample sets the selected item based on the SelectedItem binding only and therefore does what I would have expected to happen from the first sample.

<ComboBox
DisplayMemberPath="Description"
SSForm:FormItem.LabelContent="Centre"
IsEditable="{Binding Path=EditedCourse.IsCentreEditable}">
<ComboBox.ItemsSource>
<Binding
Mode="OneWay">
<Binding.Source>
<CollectionViewSource
x:Name="PART_CentresView"
Source="{Binding Source={StaticResource ViewModel}, Path=Centres, Mode=OneWay}" />
</Binding.Source>
</Binding>
</ComboBox.ItemsSource>
<ComboBox.SelectedItem>
<Binding
Path="EditedCourse.Centre"
Mode="TwoWay" />
</ComboBox.SelectedItem>
</ComboBox>

The implication is that the selected item is not necessarily what you would expect it to be.

In the first sample, the final selected item is the first (default) entry in the item source collection, and in the second sample the final selected item is the item bound to in the SelectedItem property.