WndProc in managed C# code

[Andreas Selle]

Hi,

I am sure that it must be possible to somehow hook up the WndProc of a
native Window with my own C# code. The .NETCF internally has to do that
anyway. I only wonder, how I could do so. I have seen solutions wrapping
controls with the Microsoft.WindowsCE.Forms.MessageWindows which is wrapped
again by a Control. But this is not what I am looking for. I want a straight
solution that involves nothing but appropriate thunking, even if it takes me
to write it in IL assembler.

Anyone any pointers or ideas?

Andreas

 

[Tim Wilson]

This might help you out.
http://blog.opennetcf.org/ayakhnin/PermaLink.aspx?guid=9a05b2dc-c79f-4cd8-af17-aa485fada5c7

--
Tim Wilson
..Net Compact Framework MVP

<Feedback>
Do have an opinion on the effectiveness of Microsoft Windows Mobile and
Embedded newsgroups? Let us know!
https://www.windowsembeddedeval.com/community/newsgroups
</Feedback>

 

[Andreas Selle]

This might help you out.

http://blog.opennetcf.org/ayakhnin/PermaLink.aspx?guid=9a05b2dc-c79f-4cd8-af17-aa485fada5c7

Thanks, this is a really interesting solution. Unfortunately, taking over
the message pump of the application is not an option in my project.

Any other ideas...?

Andreas

 

[Paul G. Tobey [eMVP]]

So, what you want to do is subclass a native window from managed code? You
are not going to be able to do that. Remember that, although the CLR has to
do that type of thing itself, *it is written in unmanaged code*. The
solution that Tim suggested is as close are you're going to be able to get
with .NET CF at present. Why can't you take over the message pump?

Paul T.

 

[Paul Monson (BSQUARE)]

Does this work?

http://groups.google.com/[email protected]

-Paul

 

[Paul G. Tobey [eMVP]]

That's right! Alex did get that to work, didn't he? Sorry, I'd forgotten
about how impressive that was...

Paul T.

 

[Eugene Mayevski]

Hello!
You wrote on Tue, 17 Aug 2004 11:13:47 -0700:

PGT> That's right! Alex did get that to work, didn't he? Sorry, I'd
PGT> forgotten about how impressive that was...

There's one narrow place in that solution -- HWND is obtained using
GetFocus(). While sometimes this works, this is obviously not a solution for
every window.
Does anybody know how to get native (OS-specific) HWND from WinForms window?

With best regards,
Eugene Mayevski

 

[Paul G. Tobey [eMVP]]

That's the best way. You might be able to use FindWindow() or
GetForegroundWindow() or something along those lines. Or maybe a
GetParent() until the parent is null to get the top-level window owning a
window which you *can* focus...

Paul T.

 

[Eugene Mayevski]

Hello!
You wrote on Tue, 17 Aug 2004 15:24:13 -0700:

PGT> That's the best way.

It's generally unusable way (though it can be used in some cases, of
course)...

With best regards,
Eugene Mayevski

 

[Paul G. Tobey [eMVP]]

Yes, there's not yet a managed code fix for everything you can imagine (nor,
come to think of it, is there one in unmanaged code, either). How would you
have gotten the handle if you were trying to do this from unmanaged code?
Maybe that will lead us to a solution...

Paul T.

 

[Eugene Mayevski]

Hello!
You wrote on Tue, 17 Aug 2004 15:52:20 -0700:

PGT> Yes, there's not yet a managed code fix for everything you can imagine
PGT> (nor, come to think of it, is there one in unmanaged code, either).
PGT> How would you have gotten the handle if you were trying to do this
PGT> from unmanaged code?

In unmanaged code one has the window handle from the very beginning cause he
operates with those handles. When some framework is used, usually the
framework gives access to the handle too. This is not the case with .NET CF
though (or is it?). Lack of such access stopped us from using .NET CF in
several projects -- we needed more than .NET CF could give and we couldn't
subclass a window to do more ourselves.

With best regards,
Eugene Mayevski

 

[Paul G. Tobey [eMVP]]

Well, I mean how would you do it externally, as you're trying to do it from
managed code here. I mean, you're trying to do something to someone else's
window, right? One that you did not create? I presume that this would also
be the case, if you were to try this from unmanaged code, also. You'd be
sitting there, externally, trying to access a window to which you didn't
have a handle, no?

Paul T.

 

[Alex Feinman [MVP]]

Actually the better way is by using GetCapture. I'm not aware of any side
effects of doing that (unlike SetFocus/GetFocus)

 

[Andreas Selle]

Hi,

Does this work?

http://groups.google.com/[email protected]

Thanks, that really looks good.

My topic got a lot of response, so first, thank all of you, second let me
further explain what I am planning to do.

I am currently working on a larger .NETCF based shrink-wrap-product for the
Pocket PC. Sometimes, when reading this newsgroup, I come to think that it
is probably one of the largest projects ever done based on the .NETCF .
During development I quickly came to the limits of almost all Windows.Form
controls. These are simply not sophisticated enough for creating a
shrink-wrap-product. Thus I basically replaced all of them by rewriting or
wrapping native controls and also added many more controls.

Now I consider going a step further and abandon the System.Windows.Form and
System.Drawing namespace altogether. My idea is to create a small Pocket PC
specific library that is nothing but a very thin wrapper of the native Win32
API, handling message in a WndProc and using SendMessage to interact with
the controls. So this will send me back to Win32 coding, only that I am
using C# for it. In return I hope to get the full power of the platform and
way better performance.

So, one may argue, maybe I should have used C++ from the beginning, and
perhaps you are right. But still all my business logic and all "invisible"
code will be portable .NET code, and this is good so. Actually large parts
of the logic is already used in desktop applications. But the GUI never will
be. there is no point in trying to code the GUI using the "portable"
Windows.Form namespace. Only the lamest GUI will ever be really portable. In
any other case one wants to tailor the GUI to the Pocket PC and exploit its
possibilities. Thus there is no point in trying to be Windows.Form
compatible, just for the sake of itself.

What do you think about that approach? Would anybody else be interested in a
low level alternative to the System.Windows.Form and System.Drawing
namespace?

Well, I guess this will start some discussion.

Andreas

 

[Eugene Mayevski]

Hello!
You wrote on Tue, 17 Aug 2004 16:14:51 -0700:

PGT> Well, I mean how would you do it externally, as you're trying to do it
PGT> from managed code here. I mean, you're trying to do something to
PGT> someone else's window, right? One that you did not create?

Oh, I see ...For arbitrary window there can be various ways. I read the
original post's "native window" as "unmanaged window handle", not as "some
unknown window created by other application". I am sorry for
misunderstanding. My question was related to subclassing windows, created in
managed code.

With best regards,
Eugene Mayevski

 

[Paul G. Tobey [eMVP]]

Ah! I would expect the situation to improve in the next full version of
..NET CF, but, right now the GetCapture, SetCapture method that Alex
mentioned is the only way...

Paul T.

 

[Paul G. Tobey [eMVP]]

My initial reaction is that you made an error at the point where you
realized that you needed the native controls and not the managed wrappers
for them. I wouldn't create any commercial applications of my own based on
such a library, as you might easily decide that supporting it is too much
trouble, especially when .NET CF 2.0 comes out, and I'd be stuck with a
bunch of code written for an unsupported library.

In your specific application case, you've already got the code and, as long
as you're willing to support some huge replacement for the managed code
controls, you're safe. Since you've already expended a huge amount of
effort to do what you've done, I don't see any advantage to going back and
porting the business logic, too, this time to unmanaged code. You have what
you have. If it works, it's fine.

I don't see the point, though, of trying to replace the form stuff, too.
That essentially eliminates your ability to use VS.NET to lay out your
forms, doesn't it?

Paul T.

 

[Andreas Selle]

I don't see the point, though, of trying to replace the form stuff, too.
That essentially eliminates your ability to use VS.NET to lay out your
forms, doesn't it?

Thanks for your response.

I already abandoned the VS.NET Form Designer pretty early in the project. It
produces slow code and has some known bugs. But the major reason for
abandoning it was, that I wanted to have a dynamic layout that automatically
adopts to PPC 2003 SE features like portrait/landscape mode, VGA resolution,
system font size, and the InputPanel. So I implemented my own layout engine
which dynamically layouts the controls based on all these factors. Good bye
Form Designer.

Cheers,

Andreas

 

[Paul G. Tobey [eMVP]]

Got it.

Paul T.

Thanks for your response.

I already abandoned the VS.NET Form Designer pretty early in the project. It
produces slow code and has some known bugs. But the major reason for
abandoning it was, that I wanted to have a dynamic layout that automatically
adopts to PPC 2003 SE features like portrait/landscape mode, VGA resolution,
system font size, and the InputPanel. So I implemented my own layout engine
which dynamically layouts the controls based on all these factors. Good bye
Form Designer.

Cheers,

Andreas