benwu's WebLog

Bindings, Bindings and more Bindings

2009-01-05T02:43:00Z

Bindings in WPF are great and can accomplish so many things. But how many times have you been in the position of trying to do any of the following:

Bind simple POCOs together
Apply a binding to an object outside of your xaml file
Bind the same property more than once (say once with OneWayToSource and again with a different OneWay binding)

I wrote a small utility class that helps these situations. It's called a "Join". It simply allows you to specify two bindings and it will "join" the two together. You place Joins inside a JoinContainer which is a simple ContentControl. For example:

This will bind the text of textbox1 to textbox2. It does this without using any bindings on the TextBoxes themselves, which frees you up to apply more bindings. Joins are purely oneway.

Why would you want to do this? I give you two cases, but there are more:

1. Inversion of Control

You can use the Binding engine to implement a pseudo dependency injection system. The main thing Joins give you is the ability to apply a set of bindings to local properties that do not have to be DPs and do not have to be declared on the base Type.

Let’s say you have two UserControls. One publishes a “MyService” and the other consumes it. The publish event can happen at any time and for simplicity, we use DataContext to hold the services (you could also use an inherited attached property for this).

Publisher:

<UserControl x:Class="WpfApp1.UserControl1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:local="clr-namespace:WpfApp1"

x:Name="UserControl1Root"

Height="173" Width="196">

<local:JoinContainer>

<local:JoinContainer.Joins>

<local:Join Target="{Binding MyService}" Value="{Binding ElementName=UserControl1Root, Path=MyService}" />

</local:JoinContainer.Joins>

<Grid>

<Button Margin="43,70,49,67" Name="button1" Click="button1_Click">Publish</Button>

</Grid>

</local:JoinContainer>

</UserControl>

The Join highlighted above targets the “MyService” property on the datacontext and will set it from the “MyService” property coming from UserControl1Root. That is, this sets a value on the Datacontext using local values.

Consumer:

<UserControl x:Class="WpfApp1.UserControl2"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:local="clr-namespace:WpfApp1"

Height="162" Width="206" x:Name="UserControl2Root">

<UserControl.Resources>

<local:NullToBoolConverter x:Key="converter" />

</UserControl.Resources>

<local:JoinContainer>

<local:JoinContainer.Joins>

<local:Join Target="{Binding ElementName=UserControl2Root, Path=MyService}" Value="{Binding MyService}" />

</local:JoinContainer.Joins>

<Grid>

<Button Margin="49,46,29,68" Name="button1" Click="button1_Click"

IsEnabled="{Binding ElementName=UserControl2Root, Path=MyService, Converter={StaticResource converter}}">Go!</Button>

</Grid>

</local:JoinContainer>

</UserControl>

This Join does the opposite. It sets the local MyService property on UserControl2Root from the value from the datacontext. And the great thing is you can use simple properties – though the publisher will need to implement INotifyPropertyChanged.

To declare these in xaml without Joins, you would need to declare MyService as DependencyProperties on a new base Type for both usercontrols.

2. Binding a complex Model

Say you have a model such as this:

public class ColorModel :INotifyPropertyChanged {

Color _c;

public ColorModel() {

Color = Colors.RosyBrown;

}

public Color Color {

get { return _c; }

set { _c = value; if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs("Color")); }

}

#region INotifyPropertyChanged Members

public event PropertyChangedEventHandler PropertyChanged;

#endregion

}

And you wanted to display a visual such as this:

The rectangle at the bottom is the resulting color of all three textboxes. As you think about the solution, you realize that the model given simply won’t work. The issue is that each textbox needs to be two-way to the underlying ColorModel. So, when you type a new R value, a new color gets pushed into ColorModel.Color. But when you go to write the converter for the R binding, you realize you don’t have enough contextual information to build the whole color! You are missing the values for G and B. So, it ends up that you can only make those bindings oneway if you use the ColorModel above.

Joins can help in this situation by allowing you to keep the Textbox Bindings one-way and use a Join for the other direction.

<Window x:Class="WpfApp1.MultiBindingsWindow"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

xmlns:local="clr-namespace:WpfApp1"

Title="Window1" Height="228" Width="230">

<Grid>

<local:JoinContainer>

<local:JoinContainer.Resources>

<local:RGBConverter x:Key="rgbconverter" />

</local:JoinContainer.Resources>

<local:JoinContainer.Joins>

<local:Join Target="{Binding Color}">

<local:Join.Value>

<MultiBinding.Bindings>

</MultiBinding.Bindings>

</MultiBinding>

</local:Join.Value>

</local:Join>

</local:JoinContainer.Joins>

<Grid>

<Grid.Resources>

<local:RConverter x:Key="rconverter" />

<local:GConverter x:Key="gconverter" />

<local:BConverter x:Key="bconverter" />

</Grid.Resources>

<Rectangle.Fill>

</Rectangle.Fill>

</Rectangle>

</Grid>

</local:JoinContainer>

</Grid>

</Window>

Of course, the easier approach is to just create a viewmodel with separate values for R, G, and B.

The implementation of Join is pretty simple:

public class Join : Freezable {

public object Value {

get { return (object)GetValue(ValueProperty); }

set { SetValue(ValueProperty, value); }

}

// Using a DependencyProperty as the backing store for Value. This enables animation, styling, binding, etc...

public static readonly DependencyProperty ValueProperty =

DependencyProperty.Register("Value", typeof(object), typeof(Join),

new UIPropertyMetadata(null, new PropertyChangedCallback(OnValueChanged)));

static void OnValueChanged(DependencyObject target, DependencyPropertyChangedEventArgs e) {

Join j = target as Join;

Debug.Assert(j != null);

j.Target = e.NewValue;

}

public object Target {

get { return (object)GetValue(TargetProperty); }

set { SetValue(TargetProperty, value); }

}

// Using a DependencyProperty as the backing store for Target. This enables animation, styling, binding, etc...

public static readonly DependencyProperty TargetProperty =

DependencyProperty.Register("Target", typeof(object), typeof(Join),

new FrameworkPropertyMetadata(null, FrameworkPropertyMetadataOptions.BindsTwoWayByDefault, new PropertyChangedCallback(OnTargetChanged)));

static void OnTargetChanged(DependencyObject target, DependencyPropertyChangedEventArgs e) {

Join j = target as Join;

Debug.Assert(j != null);

j.Target = j.Value;

}

protected override Freezable CreateInstanceCore() {

throw new NotImplementedException();

}

It derives from Freezable to participate in the containers inheritance context. The source for Joins can be found here:

Managed Spy -- A new way to look at Windows Forms applications

2006-02-16T03:19:00Z

I just wrote an article for msdn magazine, "Managed Spy: Deliver The Power Of Spy++ To Windows Forms With Our New Tool"

This tool is a combination of an application (exe) and library (dll). The application gives you a spy++ view of all managed processes and thier child windows. Unlike spy++, managed spy allows you to set and get all managed properties such as "BackColor" or "BorderStyle". You can also view managed events such as "MouseMove" or "ItemSelected".

The library portion allows programmatic access to controls in another process. This means you can sync on events and set properties all in your own code. You could use this to create test harnesses, create a diagnostic tool for your application after its deployed or any number of things.

Take a look at the article and let me know what you think!

New VS feature allows VS to crash!

2005-09-16T01:39:00Z

One of the newer "features" in Visual Studio 8.0 is the ability for us to collect better information about exceptions that are thrown in VS. When an exception is thrown (and unhandled), VS will generate a Watson report that will send microsoft a minidump where the exception occurred. Once we get this watson report, its easier now for us to locate the exact cause and issue a fix.

Of course, a side effect of this is that unhandled exceptions will bring down VS and may cause loss of data if you had not saved your current work. This can be particularly bad in some scenarios where your control is being used in VS and throws an exception. We do a lot to try to capture these exceptions. For example, if the exception is thrown during designer load (when your control is being hosted in the windows forms designer) we will not shutdown VS. Instead the user will see what we call the WSoD ("white screen of darn"). This indicates the callstack of the exception and disallows further edits to the form. Also, if the exception is thrown as a result of a window message sent through the designer, we will catch the error and display it to the user. An example of this is a button click or a mousehover/mouseover event. These messages are intercepted by the designer before the control in the designer is allowed to process them.

There are, however, scenarios that we can not catch during design time. If you throw an exception in a Timer_Tick event, this will not go through a designer and it will therefore bring down VS. We could not change this behavior in the runtime because doing so would be a compat breaking change (apps that used to show the exception dialog in this case would no longer show it).

It should be rare that you encounter this error. However, if you do -- it can be particularly painful. Especially if it happens whenever a certain form designer appears. What is worse, is that if a solution has stored that it should show a form immediately when you load the solution, you can end up in a situation where VS crashes every time you open the solution! One fix here is to delete the .suo file. This is a solution config file that stores what documents should be opened when the solution is opened. If there is no .suo file, no documents are opened by default. This will give you a chance to fix any errors (in code) that might be giving you problems.

Fixing Window leaks and "Class Already Registered" errors

2005-09-14T22:44:00Z

Windows Forms makes it very easy to create a rich UI experience. But it also makes it easy to leak windows or resources.

For example, say you create a new temporary AppDomain and decide to show some UI in it. If you close the AppDomain without cleaning up the windows (ie call Dispose on the Controls or close the windows via the UI), then the windows will be orphaned and will not be cleaned up properly.

It is also easy to create new threads with UI. However, if you shut down the thread that created the UI, any active windows will again be orphaned. This is because you cannot destroy a window from a thread other than the thread that created the window.

WindowCleanup : A utility to help

Below is a class called "WindowCleanup" along with a Form that displays how it can be used:

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using System.Runtime.InteropServices;
using System.Threading;

namespace WindowsApplication1
{
/// <summary>
/// Summary description for Form1.
/// </summary>
public class Form1 : System.Windows.Forms.Form
{
  private System.Windows.Forms.Button button1;
  private System.Windows.Forms.Button button2;
  /// <summary>
  /// Required designer variable.
  /// </summary>
  private System.ComponentModel.Container components = null;

  public Form1()
  {
   //
   // Required for Windows Form Designer support
   //
   InitializeComponent();

   //
   // TODO: Add any constructor code after InitializeComponent call
   //
  }

  /// <summary>
  /// Clean up any resources being used.
  /// </summary>
  protected override void Dispose( bool disposing )
  {
   if( disposing )
   {
    if (components != null)
    {
     components.Dispose();
    }
   }
   base.Dispose( disposing );
  }

  #region Windows Form Designer generated code
  /// <summary>
  /// Required method for Designer support - do not modify
  /// the contents of this method with the code editor.
  /// </summary>
  private void InitializeComponent()
  {
   this.button1 = new System.Windows.Forms.Button();
   this.button2 = new System.Windows.Forms.Button();
   this.SuspendLayout();
   //
   // button1
   //
   this.button1.Location = new System.Drawing.Point(56, 152);
   this.button1.Name = "button1";
   this.button1.TabIndex = 0;
   this.button1.Text = "CleanUp";
   this.button1.Click += new System.EventHandler(this.button1_Click);
   //
   // button2
   //
   this.button2.Location = new System.Drawing.Point(112, 80);
   this.button2.Name = "button2";
   this.button2.TabIndex = 1;
   this.button2.Text = "NewAppDomainWindow";
   this.button2.Click += new System.EventHandler(this.button2_Click);
   //
   // Form1
   //
   this.AutoScaleBaseSize = new System.Drawing.Size(5, 13);
   this.ClientSize = new System.Drawing.Size(292, 266);
   this.Controls.Add(this.button2);
   this.Controls.Add(this.button1);
   this.Name = "Form1";
   this.Text = "Form1";
   this.ResumeLayout(false);

}
#endregion

  /// <summary>
  /// The main entry point for the application.
  /// </summary>
  [STAThread]
  static void Main()
  {
   Application.Run(new Form1());
  }

  private void button1_Click(object sender, System.EventArgs e)
  {
   WindowCleanup.CloseWindows(false, false);
  }

  AppDomain domain;

  private void button2_Click(object sender, System.EventArgs e)
  {
   if (domain != null)
   {
    AppDomain.Unload(domain);
   }
   domain = AppDomain.CreateDomain("tempdomain");
   Form1 domainform = (Form1)domain.CreateInstanceAndUnwrap(typeof(Form1).Assembly.FullName,
    typeof(Form1).FullName);

domainform.Show();
}
}

class WindowCleanup
{
static bool closeNonManaged = false;
static bool closeOnlyThisThread = false;

  [DllImport("kernel32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
  public static extern int GetCurrentProcessId();
   [DllImport("user32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
  public static extern int GetWindowThreadProcessId(HandleRef hWnd, out int lpdwProcessId);
  [DllImport("user32.dll", ExactSpelling=true)]
  public static extern bool EnumChildWindows(HandleRef hwndParent, EnumWindowCallback lpEnumFunc, HandleRef lParam);
  [DllImport("user32.dll", CharSet=CharSet.Auto)]
  public static extern IntPtr SendMessage(HandleRef hWnd, int msg, int wParam, int lParam);
  [DllImport("user32.dll", CharSet=CharSet.Auto, SetLastError=true)]
  public static extern bool EnumWindows(EnumWindowCallback callback, IntPtr extraData);
  [DllImport("kernel32.dll", CharSet=CharSet.Auto, ExactSpelling=true)]
  public static extern int GetCurrentThreadId();

  public delegate bool EnumWindowCallback(IntPtr hwnd, IntPtr lParam);
  public static HandleRef NullHandleRef;

  static public void CloseWindows(bool nonManaged, bool onlyThisThread)
  {
   WindowCleanup.closeNonManaged = nonManaged;
   WindowCleanup.closeOnlyThisThread = onlyThisThread;
   EnumWindows(
    new EnumWindowCallback(CloseWindowsCallback), IntPtr.Zero);
  }

  private static bool CloseWindowsCallback(IntPtr handle, IntPtr extraParameter)
  {
   int procid1;
   int procid2 = GetCurrentProcessId();

   int threadid1 = GetWindowThreadProcessId(new HandleRef(null, handle), out procid1);
   if (procid1 == procid2)
   {
    if (closeNonManaged || NativeWindow.FromHandle(handle) != null)
    {
     if (!closeOnlyThisThread || GetCurrentThreadId() == threadid1)
     {
      SendMessage(new HandleRef(null, handle), 0x10, 0, 0);
      return true;
     }
    }
    EnumChildWindows(new HandleRef(null, handle),
     new EnumWindowCallback(CloseWindowsCallback), NullHandleRef);
   }

   return true;
  }
}
}

WindowCleanup has one main static method:

WindowCleanup.CloseWindows(nonManaged, onlyThisThread)

nonManaged: If this is true, then all windows belonging to the current process will be closed. If false, then only windows recognized as managed windows in the current appdomain will be closed.

onlyThisThread: If this is true, then only windows created on the calling thread will be closed. Use this to clean up any leftover windows before your temporary UI thread terminates.

To see the difference this class makes, run the code above by creating a new C# Windows application and copying this code over Form1.cs. When you run it, you will see 2 buttons (somewhat randomly placed).

Do this to see an error that occurs when you leak a window:

1. Run the application

2. Click the "New AppdomainWindow" button on the first form. A new form will appear and will have focus.

3. Go back to the first form and click the button again. The opened form will disappear and a new form will appear.

4. Perform step 3 additional times. Eventually you will get a "ClassAlreadyRegistered" error which occurs because a window was leaked.

Now, to see how the class fixes the problem:

1. Run the application

2. Click the "New AppdomainWindow" button on the first form. A new form will appear and will have focus.

3. Go click the "Cleanup" button on the newly opened form. That opened form will disappear.

4. Now click "NewAppdomainForm" again on the first form to show a second form again.

5. Perform step 3-4 additional times. You will not get an error because the utility class is cleaning up open windows in the appdomain that will be shut down.

Let me know if this helps you at all!

SpyWindowFinalizer and Windows Message Hooking

2005-08-17T03:40:00Z

One very powerful API that some UI developers may not be aware of is SetWindowHookEx. This api allows you to intercept all types of window messages before (or after) they are processed.

You can use this to do a whole range of neat things. For instance, you can log all messages in your app. You can use the windows journal record/playback utility to create a test harness. You can also write code to validate your application -- such as whether your application disposes all of its windows properly. If you allow a control to finalize (for example, if you remove the control from its container and do not call Dispose() on it), it can hurt the performance of your application or even worse -- cause an AV.

The sample class I wrote below (SpyWindowFinalizer) allows you to detect controls in your application that are not being properly Dispose()'d and could be leaking and causing performance problems. It allows you to take snapshots of all the controls currently valid in the application. You could use this in a UI intensive app to measure where you may have too many temporary controls. It also is a good starting sample if you'd like to do some window message hooking on your own!

using System;
using System.Drawing;
using System.Collections;
using System.ComponentModel;
using System.Windows.Forms;
using System.Data;
using System.Runtime.InteropServices;

namespace WindowSpy {
    /// <summary>
    /// This class uses SetWindowsHookEx to gather statistics and information
    /// on windows created in the application.
    /// It can easily be extended to track detailed information on each control or
    /// modify each control in some manner
    /// </summary>
    class SpyWindowFinalizer {

        /// <summary>
        /// These P/Invokes are necessary to create and manage the hook
        /// </summary>
        public delegate IntPtr HookProc(int nCode, IntPtr wParam, IntPtr lParam);
        [DllImport("User32.dll", ExactSpelling = true, CharSet = CharSet.Auto)]
        public static extern IntPtr CallNextHookEx(HandleRef hhook, int code, IntPtr wparam, IntPtr lparam);
        [DllImport("User32.dll", CharSet = CharSet.Auto)]
        public static extern IntPtr SetWindowsHookEx(int hookid, HookProc pfnhook, HandleRef hinst, int threadid);
        [DllImport("Kernel32.dll", ExactSpelling = true, CharSet = System.Runtime.InteropServices.CharSet.Auto)]
        public static extern int GetCurrentThreadId();
        [DllImport("User32.dll", ExactSpelling = true, CharSet = CharSet.Auto)]
        public static extern bool UnhookWindowsHookEx(HandleRef hhook);

        public const int WH_CALLWNDPROC = 4;    //this tells SetWindowsHookEx to hook WndProc calls
        public const int HC_ACTION = 0;         //when this comes into our callback, we should handle the message
        public const int WM_CREATE = 0x0001;    //this window message is sent when a window is created
        public const int WM_NCDESTROY = 0x0082; //this window message is sent when the nonclient area of a window is destroyed

        static HookProc hookProc;               //this is the delegate to our message hook
        static IntPtr messageHookHandle;        //the handle used for unregistering
        static Hashtable ctorTable = new Hashtable();   //our window table that holds all of the active window information we need
        static ArrayList badWindows = new ArrayList(); //a list of windows that finalized with the window active. This means the control was not disposed properly

        /// <summary>
        /// Sets up our hook
        /// </summary>
        public static void Initialize() {
            if (messageHookHandle != IntPtr.Zero) {
                return;
            }
            hookProc = new HookProc(MessageHookProc);

            messageHookHandle = SetWindowsHookEx(WH_CALLWNDPROC,
                hookProc,
                new HandleRef(null, IntPtr.Zero),
                GetCurrentThreadId());
        }

        /// <summary>
        /// Terminates our hook
        /// </summary>
        public static void Terminate() {
            GC.Collect();
            GC.WaitForPendingFinalizers();
            Application.DoEvents();

            if (messageHookHandle != IntPtr.Zero) {
                UnhookWindowsHookEx(new HandleRef(null, messageHookHandle));
                hookProc = null;
                messageHookHandle = IntPtr.Zero;
            }
            foreach (string info in ctorTable.Values) {
                badWindows.Add("**possible leak**" + info);
            }
            ctorTable.Clear();
        }

        /// <summary>
        /// Returns a list of the windows that were not disposed.
        /// </summary>
        public static IEnumerable WindowsFinalized {
            get {
                return badWindows;
            }
        }

        /// <summary>
        /// Returns the current list of all windows forms controls
        /// </summary>
        public static IEnumerable WindowsStillAlive {
            get {
                ArrayList list = new ArrayList();
                foreach (IntPtr handle in ctorTable.Keys) {
                    Control c = Control.FromHandle(handle);
                    if (c != null) {
                        list.Add(c);
                    }
                }
                return list;
            }
        }

        /// <summary>
        /// The message hook itself.
        /// It stores info when windows get created and destroyed.
        /// </summary>
        private static unsafe IntPtr MessageHookProc(int nCode, IntPtr wparam, IntPtr lparam) {
            if (nCode == HC_ACTION) {
                CWPSTRUCT* msg = (CWPSTRUCT*)lparam;
                if (msg != null) {
                    if (msg->message == WM_CREATE) {
                        Control c = Control.FromHandle(msg->hwnd);
                        if (c != null) {
                            string controlentry = c.Name + " : " + c.GetType().FullName;
                            controlentry += new System.Diagnostics.StackTrace().ToString();
                            ctorTable.Add(msg->hwnd, controlentry);
                        }
                    }
                    else if (msg->message == WM_NCDESTROY) {
                        if (ctorTable.ContainsKey(msg->hwnd)) {
                            NativeWindow w = NativeWindow.FromHandle(msg->hwnd);
                            if (w == null) {
                                badWindows.Add(ctorTable[msg->hwnd]);
                            }
                            ctorTable.Remove(msg->hwnd);
                        }
                    }
                }
            }

return CallNextHookEx(new HandleRef(null, messageHookHandle), nCode, wparam, lparam);
}

        /// <summary>
        /// parameter type for message hook
        /// </summary>
        [StructLayout(LayoutKind.Sequential)]
            [Serializable]
            public struct CWPSTRUCT {
            public IntPtr lParam;
            public IntPtr wParam;
            public int message;
            public IntPtr hwnd;
        }
    }
}

To use this in your app, write this:

  [STAThread]
  static void Main()
  {
            SpyWindowFinalizer.Initialize();

Application.Run(new Form1());

            SpyWindowFinalizer.Terminate();
            foreach(string s in SpyWindowFinalizer.WindowsFinalized) {
                System.Windows.Forms.MessageBox.Show(s);
            }
  }

This will display the control names, types and contructor callstacks for all controls that finalized before being destroyed (meaning they were likely not properly disposed of).

You can test this by creating a simple windows form application with 2 buttons. In the button click handlers do the following:

        private void button1_Click(object sender, System.EventArgs e) {
            this.button1.Parent = null;
            this.button1 = null;
        }

        private void button2_Click(object sender, System.EventArgs e) {
            GC.Collect();
            GC.WaitForPendingFinalizers();
            Application.DoEvents();
        }

Run the application,

Click button1 (it should disappear)

Click button2

Close Form1 and you should see a dialog indicating a potential bad window (being button1 which was never disposed).

For more info, see:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/hooks/hookreference/hookfunctions/setwindowshookex.asp

Control.Invoke hangs under heavy stress

2005-05-19T03:00:00Z

There have been reports of Control.Invoke hanging after the method completes. This was reported by a few customers and we have fixed this. For your reference:

ID: SRX050308605416

KB Article: 896665

The problem stems from some of the errors I describe in my previous post. IsCompleted will be "true", but the AsyncWaitHandle will never be set. The fix will be included in our next service pack.

A few workarounds exist:

1. Use a timeout in a loop checking IsComplete. Such as:

while (!result.IsCompleted) {

result.AsyncWaitHandle.WaitOne(200, false);

}

2. Access AsyncWaitHandle and call Thread.MemoryBarrier() before checking IsComplete

WaitHandle handle = result.AsyncWaitHandle;

Thread.MemoryBarrier();

if (!result.IsCompleted) {

handle.WaitOne();

}

instead of:

if (!result.IsCompleted) {

result.AsyncWaitHandle.WaitOne();

}

Both of these workarounds should work. The first has a minor perf implication.

Props to Jack Cheng at VideoTechnics for helping to correct the second fix.

Is this code threadsafe?

2005-05-06T08:16:00Z

Here is a question for you multithreaded coders out there.

After executing Thread1 and Thread2, what are the possible values for "i"?

        bool b1 = false;
        bool b2 = false;
        int i = 0;

        private void Thread1() {
            b1 = true;
            if (b2) {
                i = 1;
            }
        }

        private void Thread2() {
            b2 = true;
            if (b1) {
                i = 1;
            }
        }

The answer may surprise you. In fact, it may be zero on multiprocessor machines do to load/store optimizations made by the CPU. Try it for yourself. (note: you will always get i==1 on a single proc machine).

Pages 19-20 in http://www.microsoft.com/whdc/driver/kernel/MP_issues.mspx explain why. What is happening is that in about 1 in 1000 cases (if you actually test this on a multi-CPU machine), the CPU for Thread1 will preload the value of b2 at the same time the CPU for Thread2 is preloading the value for b1. These CPUs then write out the new values at the same time, but lo and behold. The loaded values for each bool will be false and neither if statement will be executed. Pretty interesting, yes?

On the "completely unrelated, but important" front, I have switched teams within Microsoft and I now belong to the .Net Client team (we own System.Windows.Forms, ComponentModel, Designer and a whole bunch of new features for whidbey such as ToolStrips, LayoutPanels, and DataGridView). After using .Net for five years now, I hardly remember what MFC was like. I can't imagine calling DoDataExchange or writing custom message handlers for anything. I'm not sure many MFC coders know not only how easy it is to write UI in .Net, but also how flexible it is. Only thing is -- I wish you could just override a method and see every window message being sent to the window. Guess what- you can do that! Just override protected WndProc and you have all the power in the world. Man, imagine having to add message handlers into a table (using defines you must remember beforehand) for each message you wanted and pointing to a new method. What a hassle. I think its almost too easy in .Net. Programmers in .Net have a tendency to be wasteful and create GDI objects (such as Fonts or Brushes) without cleaning them up -- but I digress.

On the "be careful, don't do that" front, do not call SetWindowLong(GWL_WNDPROC) on a background thread (that is -- a thread other than the one that owns the window handle). There is a threading issue with DispatchMessage and SetWindowLong(GWL_WNDPROC) that could cause your app to AV. To change the wndproc or subclass/unsubclass you should do this via a window message so the SetWindowLong call gets executed on the UI thread -- or -- ensure that DispatchMessage is not being called on the window handle you are changing the wndproc. Support article on this is incoming soon.

And finally, on the "be careful and DO that" front, please remember to call Dispose on all disposable objects. If you do not call dispose explicitly, you will allow the object to be garbage collected. Not only does this decrease performance because your peak workingset is higher, but you are also exposing yourself to potentially nasty threading issues because, yes, the finalizer runs on a background thread. (see previous 2 issues for examples). Finalizers also typically have different logic than the explicit dispose and finalizers are difficult to write not only because of the threading issues -- but also because finalization order is not guaranteed. For example, if A references B and B references C and C references A which one will be finalized first when none of the three are referenced by outside objects? The answer is that it is not deterministic -- and you need to remember that when writing your finalizer. More on this later.

That's it for now -- happy Mother's day!

Deployment help! in VS 2003

2004-04-30T11:30:00Z

I recieved a request for information and deployment and our deployment expert pointed me to this share. Let me know if it helps.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetcomp/html/netcfdeployment.asp

Wireless MP3 is HERE!

2004-02-17T12:49:00Z

I sent this as feedback on another persons blog -- but I've got to plug in some free advertising for Creative Labs. This setup is incredible.

http://us.creative.com/products/product.asp?category=119&subcategory=121&product=9192

It took me about 15 minutes to set up over my existing 802.11 (wireless) network at home. It would have taken less, but I have security enabled on my network, so I had to plug in the reciever into my computer's USB port to configure it. The setup consists of 2 peices of hardware:

1. The reciever (just like an 802.11 base station, but instead of an ethernet output, it gives stereo output)

2. A RF remote with LCD. You don't need line of sight with this and you can browse your entire library. My only complaint with this is that there is no pageUP/DOWN. But “SmartPlaylists” and favorites makes navigation much easier.

There is nothing like lying down listeneing to your music and browsing for the next song on your remote. Truly a new experience that you quickly get used to. I don't think I will ever have another CD again. Any CD I get as a gift will get downloaded to an MP3 file and then promptly placed in the trashbin. Oh wait, my car still can't play MP3's. Oh well, I guess thats where all my CDs will wind up.

Having assembly binding problems?

2004-02-16T19:43:00Z

If you're getting assembly load errors and cannot figure out why, you can use the fusionlog viewer to help figure it out. The fusion log will show exactly how all managed assemblies were resolved.

Check out:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrffusionlogviewerfuslogvwexe.asp

This includes retargeted assemblies. For example, if you run your device application on the desktop, compact framework assemblies are “retargeted” to desktop versions -- but only if fusion policy was applied.

If you get a cryptic assembly load error when trying to run your app, try using the above log viewer. It can save you a few hours.

Custom controls for Devices in VS 7.1

2004-02-02T18:33:00Z

A workmate and I were talking in the hallway and he mentioned that he saw several newsgroup postings that implied that the lack of device custom control support in VS 7.1 was intentional. This couldn't be anything further from the truth!

Although we do support custom controls in VS 7.1, its quite difficult to accomplish. I've added a link to the left (“Custom Control Creation for Smart Devices in VS 7.1“ that guides you through the painful process.

The truth of the matter is that device custom controls are an extremely difficult problem. The problem is that a control may use P/Invokes which are platform-dependant and will not function correctly on the desktop. In fact the Compact Framework uses many P/Invoke calls internally (as does the desktop framework). But coming in MDC (mobility devcon), we will be showcasing some features that some people have already seen at PDC last year. Custom controls will be much easier than in 7.1. In fact, most of the time you won't even realize any difference between coding against the desktop framework versus the compact framework. And the foundation of why is based on retargetting. More on retargeting next time.

First Post

2004-02-02T18:16:00Z

This is my first BLOG entry! I am a developer on the Visual Studio for Smart Devices team. My main areas of expertise are designer infrastructure, custom controls, and a hodgepodge of other areas such as Intellisense and post-compilation verification. We are very busy as MDC is approaching and we want to show off all the great work our whole team has been doing. Hope to see you there!