Home

There is one beautiful thing with the current .NET Framework and Windows 8 Apps : running your code asynchronously without blocking your UI thread.

You simply have to have a function like that, and it “magically” works:

private async void StartButton_Click(object sender, RoutedEventArgs e)
{
    try
    {
         textBox1.Text = 
         await httpClient.GetStringAsync
         ("http://msdn.microsoft.com");
    } catch (Exception) { // Process the exception. . . . }
}

Using that, you get a code that is running from the UI thread, runs into StartButton_Click, launch a task for the GetStringAsync and returns. When the GetStringAsync is finally over, the “textBox1.Text = thing” part get executed, and it works because we are still on the UI Thread. Doing so, we don’t violate the constraint of accessing UI elements from the thread that created it.

But how does it work really ? How does the Framework knows which thread is targeted and where to run the remaining of the method ?

Read the rest of this entry »

When you build an Editor, there’s always one thing you are going to need : a good property editor.

For that, I’ve chosen the one in Extended WPF Toolkit and it behaves quite nicely. But then it got tricky. In my engine, one does not simply walk set a property like that. I have that kind of structure:

 /// <summary>
 /// ...
 /// </summary>
 public GeometryMaterial GetGlobalMaterialOverride(ModifierReference reference)
 {
...
 }

/// <summary>
 /// ...
 /// </summary>
 public void SetGlobalMaterialOverride(ModifierReference reference, GeometryMaterial material)
 {
...
 }

Thus, giving it to the property grid produces no result.

Read the rest of this entry »