How to queue message to self? (C#)

  • Thread starter Thread starter Mountain Bikn' Guy
  • Start date Start date
M

Mountain Bikn' Guy

What is the C# equivalent to calling PostMessage() in Win32 in order for an
object to queue a message to itself?
Thanks
Mountain
 
I guess the answer is the same as every previous time it was asked ;)
http://groups.google.com/groups?hl=...ps?q=PostMessage+C%23&ie=UTF-8&oe=UTF-8&hl=en

However, that doesn't seem very satisfactory for C#.

Is there a nice way to do this using delegates? What I want to do is queue
an event (with args derived from EventArgs) that my object will then handle
when it finishes with it's current processing. Any other suggestions? (BTW,
my objects are all normal classes, not Forms, Controls, etc.)

Thanks,
Mountain
What is the best newsreader?
 
Hi Mountain,
Whar you are looking for is Control.BeginInvoke. When called for the thread
owning the control it works lamost like PostMessage with a slight
difference. The difference is that with BeginInvoke the next thing that is
going to be executed from the thread will be the delegate you provide to the
BeginInvoke method. With post message your message will be queued and will
wait its time to come.

HTH
B\rgds
100
 
Hi 100,
Any other ideas? I'm not using Controls or Forms. Also, I want the message
queued.
Thanks,
Mountain
 
Ok, It seems like I was mislead by the post's subject.
In this case I'm not quite sure what you want to achive. Controls are the
parts of the framework that gives you the event driven nature of the
application. IMHO only when the application works in event-driven fashion
posting messages to itself make sense. However, you can always have a list
of references to delegate objects to queue your job items and when your
code finishes its current processing it can pull the next delegate form the
list and execute its method(s). Posting messages (delegates) is simply
adding the delegate to the list - to the head or to the tail depending on
the priority you wants to give to the work item.

B\rgds
100
 
100 said:
Ok, It seems like I was mislead by the post's subject.
In this case I'm not quite sure what you want to achive. Controls are the
parts of the framework that gives you the event driven nature of the
application.
Click to expand...

100, thanks for your thoughts on this. I just want to clarify a few
additional points and respond with
a different point of view.
First, of course, event handling is certainly not limited to Controls and
Control-derived objects.
IMHO only when the application works in event-driven fashion
posting messages to itself make sense.
Click to expand...

Yes, but why assume this is limited to working with Controls? In my current
app, for example, we have collections that are changed as a result of
computations, and changes in these collections generate events. This is a
fully reactive (event-driven) system that is completely separate from any
GUI. Futhermore, check out Acitive Oberon for .NET. It is a language based
on the active object paradigm and it shows that the concept of being
event-driven need not be tied only to the GUI.
However, you can always have a list
of references to delegate objects to queue your job items and when your
code finishes its current processing it can pull the next delegate form the
list and execute its method(s).
Click to expand...

I'm hoping to leverage the event-queuing already built into Windows.
Posting messages (delegates) is simply
adding the delegate to the list - to the head or to the tail depending on
the priority you wants to give to the work item.
Click to expand...

Good points, but I still wish to use the existing infrastructure for events
rather than reinvent the wheel. Too bad PostMessage() doesn't have a
pre-built dotnet wrapper.

What is the right way to use PostMessage to post a message of a user-defined
object type?
 
Hi 100,
I ended up taking your suggestion and implementing a queue of delegates.
Thanks!
Mountain
 
Back
Top