One such not-so-subtle bug (application hang) is particularly nasty, and is described fairly well here. Distilled down, the application hangs, usually when the computer comes out of sleep mode, unlocks, or another similar event occurs. The hang happens in the firing of an event handler, called from “SystemEvents.OnUserPreferenceChanged”. The cause is that OnUserPreferenceChanged is trying to be super nice, and invoke the event in the appropriate context for each event subscriber. That means that if a Control subscribes to the event, the handler will be called on the UI thread. If user code (on a background thread) subscribes, the handler will be called on an arbitrary thread, etc. The problem occurs when, at some point in the past, a Form or Control was created on a background thread. The creation of the control “installed” a WindowsFormsSynchronizationContext as the current SynchronizationContext (this is default behavior). When OnUserPreferenceChanged attempts to Send (Invoke) to the appropriate thread context, it hangs because the WindowsFormsSynchronizationContext is on the wrong thread, and thus has no message pump with which to process messages.

Blah blah blah. Right now you’re thinking “Whatever dude, I’m a web developer, man, I’m just trying to fix this bug in that other jerk’s code.” Fair enough, you can read the linked post for more gory details. What you care about is the hard part. Well, hard for web developers anyway. By the time the app hangs, it’s too late to find out where the problem occurred. In a medium-to-large application, how do you find the control that was created on the wrong thread? Here’s how to do it in a matter of seconds.

1. Name your UI thread. If you’re not already doing this, it’s a good idea in general. I like to call mine “UI”, personally. In your “static void Main()” add this single line of code:

Thread.CurrentThread.Name = "UI";

2. Set a breakpoint deep in the bowels of the BCL. What we want to do is cause our application to break when a WindowsFormsSynchronizationContext gets assigned to the current thread. I cracked open Reflector to look at the constructor for WindowsFormsSynchronizationContext:

And I see that there’s a call to “Application.ThreadContext.FromCurrent()”. Close enough for government work, it’ll do for what I want. I didn’t feel like figuring out how to specify a constructor call when setting a breakpoint. (If you know how, leave a comment so we can all learn!) Add a breakpoint to that method call. In Visual Studio, go to the “Debug” > “New Breakpoint” > “Break at Function…” menu. In the “Function” area type the full path to the function: System.Windows.Forms.Application.ThreadContext.FromCurrent()

When you hit “OK” you’ll get a warning about IntelliSense not finding the specified location. Hit “Yes” to set the breakpoint anyway.

3. Run your application. Depending on what version of Visual Studio you’re running, and whether you’ve got source-level debugging for the Framework turned on, you’ll either get the breakpoint on some code, or you’ll get this message box:

It doesn’t matter, you can press “OK” or “Show Disassembly”, whatever floats your boat. Go to the “Call Stack” debugging window, right-click on the red breakpoint circle located at the top of the stack frame, and select “Breakpoint” > “Filter…”

4. Add a filter to this breakpoint so that it only breaks when the current threads’ name isn’t “UI”.

After you hit “OK”, continue running your application in the debugger. The first time a WindowsFormsSynchronizationContext is created and it’s not on the UI thread, BAM. There’s your problem, and there’s your stack trace allowing you to find the bad code.

This worked like a champ for me today, hopefully you have as much success with it too.

On the other hand, there are a lot of challenges like poorly named properties, confusing defaults, and possibly unexpected behavior. You really need to understand what’s going on under the covers.

For instance, if you’ve looked into .NET localizability at all, you probably know that by default resources are loaded using the CultureInfo retrieved from the System.Threading.Thread.CurrentThread.CurrentUICulture property. That’s why most guidance for manually changing the default application UI language says to set that property to a value of your choice. And well you should – it’s the only way to override the default language settings for your Windows Forms.

See, the Windows Forms designer automatically generates all sorts of useful code that you can’t (and shouldn’t) touch. Here’s an example.

Notice the ComponentResourceManager? It’s a local variable in the InitializeComponent method. The only way to alter it’s behavior is to alter the current thread’s UI culture information.

So that’s great, and even better it’s easy. When your application starts, you can load culture/language information from whatever persistence mechanism you prefer, and essentially "set it and forget it", since all Controls should be created on the same thread.

But there’s one problem with this: it only applies to UI elements (Controls).

It’s also common to load objects outside the context of the UI, perhaps with the intention of later presenting them to the user, or persisting to a file, or something else "user visible". For this, you can add an arbitrary number of resx files that contain images, strings, serialized objects, etc.

With Visual Studio 2005 and higher, these resources are available as strongly-typed properties, giving you compile-time checking and ease of use.

But here’s where our problem comes in. Overriding the default UI culture on the main thread applies only to that thread. If you load any resources from a background thread of any kind, they will be the resources for the default windows UI language.

The strongly-typed class ("Resources", in my example) offers us some relief, however, in the form of a static "Culture" property on the auto generated class. If you never touch the property, resources will be loaded using the current thread value. But if you assign your own value, you can explicitly control which resources are loaded.

Consider this debugging example where I’m stopped in the execution of a background thread. I’ve created a global static "Localization" class with a "CurrentCulture" property that I use to maintain the current UI language for my application. You can compare and contrast the values set for the current thread and the auto generated Resource static class, which my application has initialized. (I’m running the English UI for Windows, by the way.)

So, why am I posting this? Because I myself was unsure about how to correctly accomplish the goal of enabling users to select their own UI language until I noticed the auto generated "Culture" property on the Resources class. And it took me embarrassingly long to find it. Hopefully this post keeps somebody else from wasting an evening, or more.

In summary, it’s actually simple once you understand all the details. To enable a specific "non-default" language in your application:

• Set the System.Threading.Thread.CurrentThread.CurrentUICulture property to the appropriate culture, and
• Initialize all auto generated resource classes (or any custom uses of the ResourceManager class) to the appropriate culture, before loading any resources.

Once I got my ducks in a row (by perusing the MSDN documentation on the Win32 edit control, which is the foundation of the .NET TextBox anyway) I found a few resources online, but they either a) didn’t wrap the exact Win32 edit control behavior, or b) were just a one-off “send a message to the control like this”, when I’d prefer a more polished derived control with designer support, etc.

So I present CueTextBox.cs, CueComboBox.cs, and CueToolStripTextBox.cs. Here’s a simple example that hosts all 3 of them:

And, in the interest of making this as easy as possible to get, here is the code. It’s really a very simple extension – I’m not sure why this wasn’t included in the BCF (but I can guess: this will only work on Windows XP and higher, and only if visual styles are enabled).
Note that the downloaded versions have the license text, but I’ve left it off this page (the license from the downloaded files applies). Why do you care? Let Jeff Atwood tell you.

CueTextbox.cs

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

namespace Lerch.Samples
{
    public class CueTextBox : TextBox
    {
        #region PInvoke Helpers

        private static uint ECM_FIRST = 0x1500;
        private static uint EM_SETCUEBANNER = ECM_FIRST + 1;

        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
        private static extern IntPtr SendMessage(HandleRef hWnd, uint Msg, IntPtr wParam, String lParam);

        #endregion PInvoke Helpers

        #region CueText

        private string _cueText = String.Empty;

        /// <summary>
        /// Gets or sets the text the <see cref="TextBox"/> will display as a cue to the user.
        /// </summary>
        [Description("The text value to be displayed as a cue to the user.")]
        [Category("Appearance")]
        [DefaultValue("")]
        [Localizable(true)]
        public string CueText
        {
            get { return _cueText; }
            set
            {
                if (value == null)
                {
                    value = String.Empty;
                }

                if (!_cueText.Equals(value, StringComparison.CurrentCulture))
                {
                    _cueText = value;
                    UpdateCue();
                    OnCueTextChanged(EventArgs.Empty);
                }
            }
        }

        /// <summary>
        /// Occurs when the <see cref="CueText"/> property value changes.
        /// </summary>
        public event EventHandler CueTextChanged;

        [EditorBrowsable(EditorBrowsableState.Advanced)]
        protected virtual void OnCueTextChanged(EventArgs e)
        {
            EventHandler handler = CueTextChanged;
            if (handler != null)
            {
                handler(this, e);
            }
        }

        #endregion CueText

        #region ShowCueTextOnFocus

        private bool _showCueTextWithFocus = false;

        /// <summary>
        /// Gets or sets a value indicating whether the <see cref="TextBox"/> will display the <see cref="CueText"/>
        /// even when the control has focus.
        /// </summary>
        [Description("Indicates whether the CueText will be displayed even when the control has focus.")]
        [Category("Appearance")]
        [DefaultValue(false)]
        [Localizable(true)]
        public bool ShowCueTextWithFocus
        {
            get { return _showCueTextWithFocus; }
            set
            {
                if (_showCueTextWithFocus != value)
                {
                    _showCueTextWithFocus = value;
                    UpdateCue();
                    OnShowCueTextWithFocusChanged(EventArgs.Empty);
                }
            }
        }

        /// <summary>
        /// Occurs when the <see cref="ShowCueTextWithFocus"/> property value changes.
        /// </summary>
        public event EventHandler ShowCueTextWithFocusChanged;

        [EditorBrowsable(EditorBrowsableState.Advanced)]
        protected virtual void OnShowCueTextWithFocusChanged(EventArgs e)
        {
            EventHandler handler = ShowCueTextWithFocusChanged;
            if (handler != null)
            {
                handler(this, e);
            }
        }

        #endregion ShowCueTextOnFocus

        #region Overrides

        protected override void OnHandleCreated(EventArgs e)
        {
            UpdateCue();

            base.OnHandleCreated(e);
        }

        #endregion Overrides

        private void UpdateCue()
        {
            // If the handle isn't yet created, 
            // this will be called when it is created
            if (this.IsHandleCreated)
            {
                SendMessage(new HandleRef(this, this.Handle), EM_SETCUEBANNER, (_showCueTextWithFocus) ? new IntPtr(1) : IntPtr.Zero, _cueText);
            }
        }
    }
}

CueComboBox.cs

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

namespace Lerch.Samples
{
    public class CueComboBox : ComboBox
    {
        #region PInvoke Helpers

        private static uint CB_SETCUEBANNER = 0x1703;

        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
        private static extern IntPtr SendMessage(HandleRef hWnd, uint Msg, IntPtr wParam, String lParam);

        #endregion PInvoke Helpers

        #region CueText

        private string _cueText = String.Empty;

        /// <summary>
        /// Gets or sets the text the <see cref="ComboBox"/> will display as a cue to the user.
        /// </summary>
        [Description("The text value to be displayed as a cue to the user.")]
        [Category("Appearance")]
        [DefaultValue("")]
        [Localizable(true)]
        public string CueText
        {
            get { return _cueText; }
            set
            {
                if (value == null)
                {
                    value = String.Empty;
                }

                if (!_cueText.Equals(value, StringComparison.CurrentCulture))
                {
                    _cueText = value;
                    UpdateCue();
                    OnCueTextChanged(EventArgs.Empty);
                }
            }
        }

        /// <summary>
        /// Occurs when the <see cref="CueText"/> property value changes.
        /// </summary>
        public event EventHandler CueTextChanged;

        [EditorBrowsable(EditorBrowsableState.Advanced)]
        protected virtual void OnCueTextChanged(EventArgs e)
        {
            EventHandler handler = CueTextChanged;
            if (handler != null)
            {
                handler(this, e);
            }
        }

        #endregion CueText

        #region Overrides

        protected override void OnHandleCreated(EventArgs e)
        {
            UpdateCue();

            base.OnHandleCreated(e);
        }

        #endregion Overrides

        private void UpdateCue()
        {
            // If the handle isn't yet created, 
            // this will be called when it is created
            if (this.IsHandleCreated)
            {
                SendMessage(new HandleRef(this, this.Handle), CB_SETCUEBANNER, IntPtr.Zero, _cueText);
            }
        }
    }
}

CueToolStripTextBox.cs

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

namespace Lerch.Samples
{
    public class CueToolStripTextBox : ToolStripTextBox
    {
        public CueToolStripTextBox()
            : base()
        {
            if (this.Control != null)
            {
                this.Control.HandleCreated += new EventHandler(OnControlHandleCreated);
            }
        }

        public CueToolStripTextBox(string name)
            : base(name)
        {
            if (this.Control != null)
            {
                this.Control.HandleCreated += new EventHandler(OnControlHandleCreated);
            }
        }

        protected override void Dispose(bool disposing)
        {
            if (disposing)
            {
                if (this.Control != null)
                {
                    this.Control.HandleCreated -= new EventHandler(OnControlHandleCreated);
                }
            }

            base.Dispose(disposing);
        }

        void OnControlHandleCreated(object sender, EventArgs e)
        {
            UpdateCue();
        }

        #region PInvoke Helpers

        private static uint ECM_FIRST = 0x1500;
        private static uint EM_SETCUEBANNER = ECM_FIRST + 1;

        [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = false)]
        private static extern IntPtr SendMessage(HandleRef hWnd, uint Msg, IntPtr wParam, String lParam);

        #endregion PInvoke Helpers

        #region CueText

        private string _cueText = String.Empty;

        /// <summary>
        /// Gets or sets the text the <see cref="TextBox"/> will display as a cue to the user.
        /// </summary>
        [Description("The text value to be displayed as a cue to the user.")]
        [Category("Appearance")]
        [DefaultValue("")]
        [Localizable(true)]
        public string CueText
        {
            get { return _cueText; }
            set
            {
                if (value == null)
                {
                    value = String.Empty;
                }

                if (!_cueText.Equals(value, StringComparison.CurrentCulture))
                {
                    _cueText = value;
                    UpdateCue();
                    OnCueTextChanged(EventArgs.Empty);
                }
            }
        }

        /// <summary>
        /// Occurs when the <see cref="CueText"/> property value changes.
        /// </summary>
        public event EventHandler CueTextChanged;

        [EditorBrowsable(EditorBrowsableState.Advanced)]
        protected virtual void OnCueTextChanged(EventArgs e)
        {
            EventHandler handler = CueTextChanged;
            if (handler != null)
            {
                handler(this, e);
            }
        }

        #endregion CueText

        #region ShowCueTextOnFocus

        private bool _showCueTextWithFocus = false;

        /// <summary>
        /// Gets or sets a value indicating whether the <see cref="TextBox"/> will display the <see cref="CueText"/>
        /// even when the control has focus.
        /// </summary>
        [Description("Indicates whether the CueText will be displayed even when the control has focus.")]
        [Category("Appearance")]
        [DefaultValue(false)]
        [Localizable(true)]
        public bool ShowCueTextWithFocus
        {
            get { return _showCueTextWithFocus; }
            set
            {
                if (_showCueTextWithFocus != value)
                {
                    _showCueTextWithFocus = value;
                    UpdateCue();
                    OnShowCueTextWithFocusChanged(EventArgs.Empty);
                }
            }
        }

        /// <summary>
        /// Occurs when the <see cref="ShowCueTextWithFocus"/> property value changes.
        /// </summary>
        public event EventHandler ShowCueTextWithFocusChanged;

        [EditorBrowsable(EditorBrowsableState.Advanced)]
        protected virtual void OnShowCueTextWithFocusChanged(EventArgs e)
        {
            EventHandler handler = ShowCueTextWithFocusChanged;
            if (handler != null)
            {
                handler(this, e);
            }
        }

        #endregion ShowCueTextOnFocus

        private void UpdateCue()
        {
            // If the handle isn't yet created, 
            // this will be called when it is created
            if ((this.Control != null) && (this.Control.IsHandleCreated))
            {
                SendMessage(new HandleRef(this.Control, this.Control.Handle), EM_SETCUEBANNER, (_showCueTextWithFocus) ? new IntPtr(1) : IntPtr.Zero, _cueText);
            }
        }
    }
}

This stuff is all very cool – but can also make some bugs seriously hard to find. Here’s one I ran across this past week.

Our soon-to-be-public .NET API follows one of the async models recommended by Microsoft, providing two flavors of every synchronous method:

void Foo();
void FooAsync(AsyncCompletedEventHandler callback, object state);

Under the covers, we make use of the AsyncOperation and AsyncOperationManager classes found in the System.ComponentModel namespace. Under one particular circumstance I found that the async operation would complete successfully, but the callback would never get called. I traced the code to our call to AsyncOperation.PostOperationCompleted, which completed successfully. Somewhere in frameworkland it just never called the specified callback. That’s when I began looking into the AsyncOperation classes and how they interact with the SynchronizationContext (and what the heck the SynchronizationContext even was). It’s actually relatively simple. When you construct an AsyncOperation, it keeps a copy of the current SynchronizationContext (which could be “plain”, or WindowsForms, or AspNet) and uses the saved copy to post the callback’s execution onto. Nothin’ to it, right?

Well, in my case, a background thread was firing an event that caused a lot of these Async calls (don’t ask ), and somewhere in the chain of these many Async calls a subtle bug was causing a Control to be created. When a control is created, or a message loop started, the current synchronization context will be replaced with a new WindowsFormsSynchronizationContext for the current thread, unless the WindowsFormsSynchronizationContext.AutoInstall static property is set to false (it’s true by default). This relies on the fundamental windows rule that all controls must be created on the UI thread. Everything continued executing successfully, except that the sync context was now referencing a MarshalingControl on the wrong thread (a thread without a message loop) so on all subsequent “AsyncCompleted” callbacks, BeginInvoke was being called on the MarshalingControl and would fall into oblivion and never be called.

That itself, aside from my long and boring explanation, wouldn’t have been so bad (after a little research), except that I couldn’t find any instance of a control being created! It ended up that in a relatively recent conversion from the .NET 1.1 ContextMenu to .NET 2.0′s ContextMenuStrip throughout our applications I hadn’t taken into account the fact that referencing a ToolStripMenuItem’s DropDownItems property will create a new DropDown control under the covers automatically if it didn’t already exist. Our application’s “mini”-commanding architecture was causing the UI to update itself when new “actions” were added, but failed to take into account that actions were being added from a background thread (whoops–there’s the root bug). So a simple call to “this.DropDownItems.Add(new ToolStripMenuItem(action));” was creating a control if there were no pre-existing items, and resetting the current SynchronizationContext. One question I have is why I never saw a System.InvalidOperationException in debug mode like I would’ve expected for my cross-thread accessing of the DropDownItems property.

<sigh> It’s times like these that I both feel dumb and feel smart – dumb because they were rather simple fundamental mistakes, and smart because I learned a lot investigating it. I was also able to relay some information to the team that they didn’t know either.

Why do I tell you all this? Let me summarize:

• ToolStripMenuItem.DropDownItems will create a control if one hasn’t been created. (And a healthy reminder: only reference methods, properties, and fields of controls on the UI thread!)
• An inadvertant change in the current SynchronizationContext (a static thread-specific property) can cause unexpected conditions – which can be hard to track down because they don’t appear to “fail” explicitly. And in my case, the buggy code was in no way related to the point where I first saw the problem.

Also, if you happen to be so lucky as to be someone writing custom applications using our API, I can assure you that we are dogfooding it like crazy (unlike our last API), and that does nothing but bring pure benefit to you, the customer.

After reading his series (which I encourage you to do), I went back and created a class I called ControlRedrawLock which can be used to, well, lock redrawing of a control.

One word of caution, however. I couldn’t believe something like this hadn’t been included as a method on Control, so I did some reflectorin’ to look around. Control.BeginUpdateInternal and Control.EndUpdateInternal do exactly what I was looking for, including ref counting and everything. But sure enough, as are many useful things, they are marked as internal. On the other hand, I could see that if these were exposed publicly on all controls it could be a potential source of some confusing bugs. A few select controls do expose this (such as ComboBox), probably just where it makes sense. The word of warning, then, is to be very careful in your use of this class. You might get undesirable results if you combine it’s usage with parts of controls that internally call EndUpdateInternal as my class will re-enable drawing regardless of what’s going on. That said, enjoy!

Here’s how you would use it:

using (new ControlRedrawLock(this))
{
    // Do something
}

And here’s the code:

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;

namespace Lerch.UI
{
    public class ControlRedrawLock : IDisposable
    {
        [DllImport("user32.dll", EntryPoint="SendMessage")]
        public static extern int SendMessage(IntPtr hWnd, uint Msg, int wParam, int lParam);

        public static int WM_SETREDRAW = 0x000B;

        private Control _control;
        private bool _invalidate;
        private bool _disabledRedraw = false;

        public ControlRedrawLock(Control control) : this(control, true)
        {
        }

        public ControlRedrawLock(Control control, bool invalidate)
        {
            try
            {
                _control = control;
                _invalidate = invalidate;

                if (IsValidControl())
                {
                    // Lock drawing
                    SendMessage(_control.Handle, WM_SETREDRAW, 0, 0);
                    _disabledRedraw = true;
                }
            }
            catch
            { }
        }

        private bool IsValidControl()
        {
            return ((_control != null) && (_control.IsHandleCreated));
        }

        #region IDisposable Members

        public void Dispose()
        {
            try
            {
                if (IsValidControl() && _disabledRedraw)
                {
                    // Unlock drawing
                    SendMessage(_control.Handle, WM_SETREDRAW, 1, 0);
                    if (_invalidate)
                    {
                        // Invalidate the control to trigger a re-paint.
                        _control.Invalidate(true);
                    }
                }
            }
            catch
            { }
        }

        #endregion
    }
}

If you don’t know what InvokeRequired is, or why you want to use it, you should definitely read the MSDN docs to get up to speed. In fact, much of what I want to say is available on that page. It’s also accompanied by a fairly simple-but-complete multithreading WinForms example.

Most examples show something like this:

1 private void UpdateTheUI()
2 {
3     if (this.InvokeRequired)
4     {
5         this.BeginInvoke(new MethodInvoker(UpdateTheUI));
6     }
7     else
8     {
9         // Update the control, etc.
10     }
11 }

That’s all fine and good, but there are a few scenarios that can affect this code. Some of them can be mitigated by your design. For example, did you know that Control.InvokeRequired can return false even when you’re calling it from a different thread? Yep, it’s true! From the lips of MSDN:

This means that InvokeRequired can return false if Invoke is not required (the call occurs on the same thread), or if the control was created on a different thread but the control’s handle has not yet been created.

A common scenario where this might occur is if a background process is started from the control’s constructor (typically considered a no-no, but sometimes it might be necessary). If the background work completes quicker than expected you could be trying to update a UI that hasn’t even been shown yet. The solution in this case is to check the IsHandleCreated property if InvokeRequired is false, and defer the update until the control’s handle has been created. (Save yourself some time: don’t check the Handle property for null or IntPtr.Zero–referencing the property at all will create a handle on the spot–and likely on the wrong thread, too.)

There’s one more gotcha I want to mention. After background processing has elapsed, it’s entirely possible your control has since been disposed. It’s always important to check IsDisposed before updating your UI. A common problem we ran into at work (one which I took part in) was that we threw in a check for IsDisposed at the top of the method and return if it was true, like this:

1 private void UpdateTheUI()
2 {
3     if (this.IsDisposed) return;
4 
5     if (this.InvokeRequired)
6     {
7         this.BeginInvoke(new MethodInvoker(UpdateTheUI));
8     }
9     else
10     {
11         // Update the control, etc.
12     }
13 }

Unfortunately we forgot that besides the InvokeRequired property the only thread-safe methods on the Control class are: Invoke, BeginInvoke, EndInvoke, and CreateGraphics (all assuming the handle has been created, of course). Notice that IsDisposed isn’t in that list?

Here’s an example that (to my current knowledge) addresses all of these potential issues, at least in one way or another. At this point you can call UpdateTheUI from almost any context and it won’t bomb. That’s not a promise that it will do exactly what you hope it will do (i.e. update the UI) but that’s where your control’s design comes in.

1 private void UpdateTheUI()
2 {
3     if (this.InvokeRequired)
4     {
5         this.BeginInvoke(new MethodInvoker(UpdateTheUI));
6     }
7     else
8     {
9         if (this.IsDisposed) return;
10 
11         if (!this.IsHandleCreated)
12         {
13             // Background processing completed before the
14             // control's handle has been created. Do whatever it takes
15             // to indicate that a deferred update must occur (after the handle has
16             // been created).
17 
18             _deferUIUpdate = true;
19             return;
20         }
21 
22         // Update the control, etc.
23     }
24 }

I was working on creating a Form that intercepts the WM_MOUSEACTIVATE message to prevent a click from stealing focus from another form (i.e. a menu, or a drop down list). In my experimentation I had a “grand” idea to create a class that implements IMessageFilter which would keep a map of the Handle of a form and all its controls (and their controls, etc.) and intercept all WM_MOUSEACTIVATE messages for the “registered” controls. (Keep in mind I was experimenting, and the intended use of this is a small form that doesn’t have a huge control tree to track.)

I wrote probably about 100 lines of code (fortunately my lesson was learned on a small scale first!) to handle the registering of controls, the watching of controls added to Controls collections, the cleaning up on disposal, and so on. Finally my masterpiece was complete, I ran it, and … nothing happened. Huh? Debugging showed that the message filter was active and kicking, my controls were registered, but I was never receiving the WM_MOUSEACTIVATE message (as I did when I overrode WndProc). A bit of Google searching turned up the answer (below).

So I guess I learned two lessons:

1. Start small and work up from there, and
2. An IMessageFilter only processes windows messages that are posted (PostMessage) and not sent (SendMessage)—and WM_MOUSEACTIVATE is sent. Had I tried to intercept this message via the filter before I created all the supporting code, I could’ve saved myself some time.

Live and learn! (And pass it on!)

What is Hawkeye? From the website:

“Hawkeye is the only .Net tool that allows you to view, edit, analyze and invoke (almost) any object from a .Net application. Whenever you try to debug, test, change or understand an application, Hawkeye can help.”

I haven’t put it through any sort of paces yet, but I was blown away that I was able to attach to my .NET Outlook add-in and change properties in real-time. I think this will quickly become a valued debugging tool. Download it and give it a whirl!

(via Mike Gunderloy’s Daily Grind)

I find it useful to be able to right-click a property in the designer and select “Reset” to return it to the control’s default value. Much more important is the ability to automatically tag a property as localizable so without any other code it’s value will be initialized from the resource file.

Here’s the article