Question

The current declaration of SendMessage over at PInvoke.net is:

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

Note: The hWnd is no longer an IntPtr, and has been replaced with HandleRef. A very loose explanation for the change is given:

You can replace ‘hWnd’ with ‘IntPtr’ instead of ‘HandleRef’. However, you are taking a risk in doing this – it may cause your code to crash with race conditions. The .NET runtime can, and will, dispose your window handles out from under your message – causing all sorts of nasty problems!

Someone wiki’d a followup question:

Question: Can’t this last issue be addressed with marshaling, specifically pinning?

And someone answered:

Answer: You can use GC.KeepAlive() right after the SendMessage() with the Form object as the parameter to KeepAlive().

All this ‘disposing your form underneath you’ seems odd to me. SendMessage is a synchronous call. It will not return until until the sent message has been processed.

The implication then is that a form handle can be destroyed at any time. For example:

private void DoStuff() {    //get the handle    IntPtr myHwnd = this.Handle;      //Is the handle still valid to use?    DoSomethingWithTheHandle(myHwnd); //handle might not be valid???      //fall off the function } 

This means that the window handle can become invalid between the time i use it and the time the method ends?

---

Update One

i understand the notion that once a form goes out of scope, it’s handle is invalid. e.g.:

private IntPtr theHandle = IntPtr.Zero;  private void DoStuff() {    MyForm frm = new MyForm())     theHandle = frm.Handle;     //Note i didn't dispose of the form.    //But since it will be unreferenced once this method ends    //it will get garbage collected,    //making the handle invalid } 

It’s obvious to me that the form’s handle is not valid once DoStuff has returned. The same would be true no matter what the technique – if the form is not held in some scope, it is not valid to use.

i would disagree with (todo link guy) in that a form will stick around until all send messages have been received. The CLR does not know who may have been given my form’s window handle, and has no way of knowing who may call SendMessage() in the future.

In other words, i cannot imagine that calling:

IntPtr hWnd = this.Handle; 

will now prevent this from being garbage collected.

---

Update Two

i cannot imagine having a window handle around will keep a form from being garbage collected. i.e.:

Clipboard.AsText = this.Handle.ToString(); IntPtr theHandle = (IntPtr)(int)Clipboard.AsText; 

---

Answer

But these are illevant points – the original question still is:

Can the runtime dispose a form’s handle out from under me?

The answer, it turns out, is no. The runtime will not dispose of a form out from under me. It will dispose of an unreferenced form – but unreferenced forms are not under me. ‘Under Me’ means i have a reference to the form.

On the other hand, a Form object’s underlying Windows window handle can be destroy out from under me (and really how could it not – window handles are not reference counted – nor should they be):

IntPtr hwnd = this.Handle; this.RightToLeft = RightToLeft.Yes; //hwnd is now invalid 

It’s also important to note that HandleRef will not help prevent the problems caused by creating object wrappers around Windows window handles:

Reason 1 If a form object is being destroyed because you didn’t have a reference to it – then you’re just stupid for trying to talk to a form that by rights should no longer exist. Just because the GC hasn’t gotten around to it yet doesn’t make you smart – it makes you lucky. A HandleRef is a hack to keep a reference to the form. Rather than using:

HandleRef hr = new HandleRef(this, this.Handle); DoSomethingWithHandle(this.Handle); 

you could easily use:

Object o = this; DoSomethingWithHandle(this.Handle); 

Reason 2 HandleRef will not prevent a form from re-creating it’s underlying window handle, e.g.:

HandleRef hr = new HandleRef(this, this.Handle); this.RightToLeft = RightToLeft.Yes; //hr.Hande is now invalid 

So while the original modifier of SendMessage on P/Invoke did point out a problem, his solution isn’t a solution.

Answer 1

Often when you are calling SendMessage, you are doing so from another thread or at least another component separate from your Form. I assume the point being made is that just because you have an IntPtr which at one point contained a valid window handle, you cannot assume that it still is a valid.

Say you had this class:

class MyClass {    IntPtr hwnd;    public MyClass(IntPtr hwnd) {       this.hwnd = hwnd;    }    ...     private void DoStuff()    {        //n.b. we don't necessarily know if the handle is still valid        DoSomethingWithTheHandle(hwnd);    } } 

and somewhere else:

 private void DoOtherStuff() {      Form f = new Form();      mc = new MyClass(f.Handle);  } 

then because f has gone out of scope, its Dispose will eventually get called by the GC finalizer. That’s why you might need to use Gc.KeepAlive in this type of situation. f must stay alive until mc is finished with the handle.