User defined mesage in C#?

[=?Utf-8?B?RXJpYw==?=]

When porting the Win32/MFC code to C#, I do not know how to deal with those
user defined windows messages. I just cannot cannot find an equivalent thing
in C#. Those messsages are so convenient in C/C++, especially when a thread
needs to inform the main GUI thread something, then continue its tasks:

ThreadFunc()
{
Doing something...
SendMessage(WM_USER+123,....);
Continue doing things....
}

What's the .NET way to accomplish this?

--
Eric

[=?Utf-8?B?RXJpYw==?=]

I know I can use the backgroundWorker to accomplish this, but, I cannot
suspend/resume it as I can do with normal thread.

--
Eric
"Eric" wrote:

When porting the Win32/MFC code to C#, I do not know how to deal with those
user defined windows messages. I just cannot cannot find an equivalent thing
in C#. Those messsages are so convenient in C/C++, especially when a thread
needs to inform the main GUI thread something, then continue its tasks:

ThreadFunc()
{
Doing something...
SendMessage(WM_USER+123,....);
Continue doing things....
}

What's the .NET way to accomplish this?

--
Eric

[Peter Duniho]

On Fri, 20 Apr 2007 09:28:02 -0700, Eric <Er**@discussions.microsoft.com>
wrote:

When porting the Win32/MFC code to C#, I do not know how to deal with
those user defined windows messages. I just cannot cannot find an
equivalent thing in C#. Those messsages are so convenient in C/C++,
especially when a thread needs to inform the main GUI thread something,
then continue its tasks: [...]

Well, if you want to do a straight one-for-one port, .NET does have a way
for you to actually get at the window proc, overriding it so that you can
still process user-defined messages.

The .NET-friendly methods involve delegates and/or events (that is, .NET
events...not to be confused with Windows event handles). With a delegate,
you can use Control.Invoke() or Control.BeginInvoke() (which are like
SendMessage() and PostMessage(), respectively) to have a method run on the
GUI thread. This would be appropriate when you have a single method that
some thread needs to run and which needs to be executed on the GUI thread.

Alternatively, you can use an event to set up a "subscriber-based"
notification system. Events don't in and of themselves address the
cross-thread issue, and they still require the use of delegates. So the
reason you'd use an event is if you view your user-message as more of a
notification than a "do this work now" sort of thing. The difference is,
IMHO, more conceptual than practical.

Pete

[=?Utf-8?B?RXJpYw==?=]

Great information. The Control.Invoke() or Control.BeginInvoke() is just what
I want. Thanks!

--
Eric
"Peter Duniho" wrote:

On Fri, 20 Apr 2007 09:28:02 -0700, Eric <Er**@discussions.microsoft.com>
wrote:

When porting the Win32/MFC code to C#, I do not know how to deal with
those user defined windows messages. I just cannot cannot find an
equivalent thing in C#. Those messsages are so convenient in C/C++,
especially when a thread needs to inform the main GUI thread something,
then continue its tasks: [...]

Well, if you want to do a straight one-for-one port, .NET does have a way
for you to actually get at the window proc, overriding it so that you can
still process user-defined messages.

The .NET-friendly methods involve delegates and/or events (that is, .NET
events...not to be confused with Windows event handles). With a delegate,
you can use Control.Invoke() or Control.BeginInvoke() (which are like
SendMessage() and PostMessage(), respectively) to have a method run on the
GUI thread. This would be appropriate when you have a single method that
some thread needs to run and which needs to be executed on the GUI thread.

Alternatively, you can use an event to set up a "subscriber-based"
notification system. Events don't in and of themselves address the
cross-thread issue, and they still require the use of delegates. So the
reason you'd use an event is if you view your user-message as more of a
notification than a "do this work now" sort of thing. The difference is,
IMHO, more conceptual than practical.

Pete