Strange NativeWindow class behavior!

[Arthur Freund]

Hi,

for our application, we want to keep track on whether the user is
currently in a text box or not. So I simply retrieved the handle
of the focus window and tried System.Window.Forms.Control.FromHandle
to get the control that is responsible for this handle.

Now, this works fine. The next thing I did, was to cast as TextBoxBase
to get a clue on whether the control is a text box, which does work
also.

I also created a class that derives from NativeWindow, added an override
to the message procedure and handled the desired messages.

Now comes the strange effect:
I called Assign(handle) on this class and everything works fine. When I
call Release() on the class, the next time a call Control.FromHandle
returns null all the time.

Any ideas on this? I know, that there is a NativeWindow.FromHandle, but
that does not help me, since I need to filter some messages.


Any help will be appreciated.

Thanks in advance
Arthur

 

[Xin Huang]

If you ildasm Control.FromHandle, you can find it is based on
NativeWindow.FromHandle. They share the same handle map, so releasing the
handle from NativeWindow does affect Control.FromHandle.

Regards,
Xin

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. (c) 2003 Microsoft Corporation. All
rights reserved.

 

[Arthur Freund]

If you ildasm Control.FromHandle, you can find it is based on
NativeWindow.FromHandle. They share the same handle map, so releasing the
handle from NativeWindow does affect Control.FromHandle.

Regards,
Xin

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. (c) 2003 Microsoft Corporation. All
rights reserved.

If you ildasm Control.FromHandle, you can find it is based on
NativeWindow.FromHandle. They share the same handle map, so releasing the
handle from NativeWindow does affect Control.FromHandle.

Regards,
Xin

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. (c) 2003 Microsoft Corporation. All
rights reserved.

Well, maybe there is some misunderstanding here, I call the native Win32
API GetFocusWindow (or something similar) by PInvoke to retrieve the
(native) handle of the window. Now, just in order to get the information
on whether it is a managed control or not, I'm calling
Control.FromHandle. This returns null, if there is no managed control
for that handle (meaning it must then be something native).

What I do then is to create a new instance of the class NativeWindow and
call AssignHandle(native window handle). Then, after a while call
ReleaseHandle(). This causes the effect I mentioned.

Now, from what I know about native window handling and subclassing,
superclassing etc. this behaviour is simply wrong. As far as I'm
concerned, I just injected another layer into the window procedure.
And if I remove it (via ReleaseHandle), it should simply restore the
previous one. (This is the reason, why there is also a DestroyHandle
method?).

Anyway, I looked into the IL Code myself, and for what I see (or
interpret the code for), is that it simply replaces the native window in
the list with my new one, and I now have a child that is the original
native window. So calling base.WndProc simply forwards the message to
the previous native window. However, if I call ReleaseHandle() the
native window is simply removed from the list (without restoring it to
the previous value).

In my eyes, this simply is a bug!

Thanks
Arthur

 

[Xin Huang]

We can only have one managed subclass for any HWND. If you subclass a HWND
a second time, the second guy blows away the first, as you see in the IL
code. This is the way NativeWindow is designed.

So I'm afraid you need to subclass the control manually (not using
NativeWindow).

Regards,
Xin

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. (c) 2003 Microsoft Corporation. All
rights reserved.