DefWndProc question

[ethon]

(This is C# btw)

I have a subclass that handles UDP operations from an external SimuLink application, but I don't want this subclass to be a form. Just something that opens another SimConnect connection to transmit/set information.

As I understand it, DefWndProc is a method of Forms, so how do I register this connection to receive messages?

I get an exception ('no suitable method to override') because this is not a Form.

        protected override void DefWndProc(ref Message m)
        {
            if (m.Msg == WM_USER_SIMCONNECT)
            {
                if (simConnectRecv != null)
                {
                    simConnectRecv.ReceiveMessage();
                }
            }
            else
            {
                base.DefWndProc(ref m);
            }
        }

Do I not need this then if this is running as essentially a console application? I'm slightly confused.

 

[ethon]

Also, when I try to initialize my new SimConnect client

simConnectRecv = new SimConnect("SimConnect - UDP Recv.Update", this.Handle, WM_USER_SIMCONNECT, null, 0);

I get an exception because, again, its not a Form, so I dont have a Window Handle.

How do I set this up?

 

[ziporama]

Hello,
couple of possible ways, depending on what you are doing.

1) If you use the managed simconnect wrapper, the message pump is done for you internally so there is no need as far sa I know.

2) NativeWindow will allow you to subclass a regular system.windows.form and give you a handle to it in the form of an IntPtr if you need one in .NET.

3) If you use WPF, there's yet another conversion class, the name escapes me at the moment, but same deal - you can subclass a native window.

Hope this helps.

Etienne

 

[beatle]

No need to go through quite all of that. You just need to use the event handle mechanism provided. See this blog entry for info on how to use this (the blog entry is about WPF mostly, but the same concepts will work with a console app as well (or in your case, an non-UI based class object)).

I may have a better solution available in a couple of months (I've been working on a replacement managed client library that doesn't rely on the existing native library, its 100% managed code, and supports several .Net-isms to make life easier), but until then, the above should get you going.

Tim