Bug in NativeWindow.ReleaseHandle?

[Claes Bergefall]

I'm trying to temporarily subclass a window and tried using
the NativeWindow class, but...

I found some weird behaviour with the ReleaseHandle method
in the NativeWindow class. It seems as if that method messes
up the internal state of the application.

To reproduce the problem I created a simple Form with a
button on it, and placed the following code in the button click
event handler:

Dim h As IntPtr
Dim ctrl As Control
Dim wnd As New NativeWindow
wnd.AssignHandle(Me.Handle)
h = Me.Handle
ctrl = Control.FromHandle(h)
wnd.ReleaseHandle()
h = Me.Handle
ctrl = Control.FromHandle(h)

The first call to Control.FromHandle works as expected
and returns the form instance (Me). The second one doesn't; it
returns null. Both calls to Me.Handle works correctly though.

If you call the above code twice (i.e. press the button twice)
the message handling for the form breaks down! It doesn't paint
correctly, you can't close it fully etc

Found a thread about this that states that this problem exists in 1.0
but has been fixed in 1.1. Well, I use 1.1 and it doesn't look like
it has been fixed. Here is the thread:
http://groups.google.se/groups?hl=s...%20ReleaseHandle&as_ugroup=*dotnet*&lr=&hl=sv

Ideas or comments anyone?

/claes

 

[Jeffrey Tan[MSFT]]

Hi Claes,

I have reproduced out this behavior, I will spend some more time on this
issue. I will reply to you ASAP. Thanks for your understanding.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Jeffrey Tan[MSFT]]

Hi Claes,

Sorry for letting you wait for so long!

If we use the Lutz Roeder's .Net Reflector to view Control.FromHandle()
method, we can see that it calls Control.FromHandleInternal(handle). Then
Control FromHandleInternal(IntPtr handle)'s code lists below:

internal static Control FromHandleInternal(IntPtr handle)
{
NativeWindow window1 = NativeWindow.FromHandle(handle);
while ((window1 != null) && !(window1 is Control.ControlNativeWindow))
{
window1 = window1.PreviousWindow;
}
if (window1 is Control.ControlNativeWindow)
{
return ((Control.ControlNativeWindow) window1).GetControl();
}
return null;
}

As we can see that, Control.FromHandle() actually returns
NativeWindow.FromHandle(handle) to get the reference. So if we called
ReleaseHandle method, the handle is removed from the internal window hooked
table, then the NativeWindow.FromHandle can not get any NativeWindow object
from the internal window hooked table, so the null is return.

So I think this is by design.

Hope this informatin makes sense to you.
====================================
Thank you for your patience and cooperation. If you have any questions or
concerns, please feel free to post it in the group. I am standing by to be
of assistance.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Claes Bergefall]

Yes, I looked at it using .NET Reflector aswell.

This looks like a bug to me. ReleaseHandle should restore
the window procedure to what it was before calling
AssignHandle. How is it supposed to be used if it doesn't?

If this is by design you should really consider redesigning it.
Perhaps a RestoreHandle method could be provided.

Do you know of any other way of temporarily subclassing
a window (apart from writing the PInvoke stuff myself)?

Thanks

/claes

 

[Jeffrey Tan[MSFT]]

Hi Claes,

Thanks for your feedback!

I am glad my reply makes sense to you.

Actually, for this issue, I have helped you to forward it to the product
group. If you like, you may also feedback this issue through the link below:
http://register.microsoft.com/mswish/suggestion.asp

So far as I know, NativeWindow is the standard .Net way of doing subclass.
Without P/invoke, I can not think of another way to workaround
NativeWindow class, as .Net did not expose another way.

HTH.

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

 

[Claes Bergefall]

Thanks for the help

I've worked around the issue for now. If I need it
again in the future I'll just write my own subclassing code.

/claes

 

[Jeffrey Tan[MSFT]]

Ok, if you need further help, please feel free to tell me. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.