Hi,
I am tring to pass messages between threads, using the good old C++ I would call the GetMessage/PostThreadMessage APIs, Now, I am using C# and i can't find any equivalenty for these calls, any Idea how to communicate between threads and access the threads message queue will be appriciated...
--
Nadav http://www.ddevel.com 9 13406
These were user interface APIs, not thread communication APIs. The
"System.Windows.Forms.Control.Invoke" function wraps them in a clean,
object-oriented fashion (the message loop is wrapped in the Application
class IIRC).
Don't use them for communication between non-UI threads. Use pipes,
sychnronization objects, locks, events & friends for that purpose. If
anybody will ever have to find a bug in your code, she will definitely
appreciate that!
Niki
"Nadav" <Na***@discussions.microsoft.com> wrote in
news:37**********************************@microsof t.com... Hi,
I am tring to pass messages between threads, using the good old C++ I would call the GetMessage/PostThreadMessage APIs, Now, I am using C# and i can't find any equivalenty for these calls, any Idea how to communicate between threads and access the threads message queue will be
appriciated... -- Nadav http://www.ddevel.com
Hi Niki, Thanks for your response, Still, I didn't understand from your response if there is an equivalent for the threads message queue management Win32 API, there must be a .NET class for the threads message queue management, Thread message queue management is an elementary feature in inter thread communication and i find it hard to believe that the .NET framework doesn't support the inter-thread communication in this way, Still, I couldn't find any equivalent to the Win32 message queue equivalents ( e.g. GetMessage, PostThreadMessage, ... ).
--
Nadav http://www.ddevel.com
"Niki Estner" wrote: These were user interface APIs, not thread communication APIs. The "System.Windows.Forms.Control.Invoke" function wraps them in a clean, object-oriented fashion (the message loop is wrapped in the Application class IIRC). Don't use them for communication between non-UI threads. Use pipes, sychnronization objects, locks, events & friends for that purpose. If anybody will ever have to find a bug in your code, she will definitely appreciate that!
Niki
"Nadav" <Na***@discussions.microsoft.com> wrote in news:37**********************************@microsof t.com... Hi,
I am tring to pass messages between threads, using the good old C++ I would call the GetMessage/PostThreadMessage APIs, Now, I am using C# and i can't find any equivalenty for these calls, any Idea how to communicate between threads and access the threads message queue will be appriciated... -- Nadav http://www.ddevel.com
Nadav <Na***@discussions.microsoft.com> wrote: Hi Niki, Thanks for your response, Still, I didn't understand from your response if there is an equivalent for the threads message queue management Win32 API, there must be a .NET class for the threads message queue management, Thread message queue management is an elementary feature in inter thread communication and i find it hard to believe that the .NET framework doesn't support the inter-thread communication in this way, Still, I couldn't find any equivalent to the Win32 message queue equivalents ( e.g. GetMessage, PostThreadMessage, ... ).
Interthread communication shouldn't use the Win32 message queue unless
it's UI-related, I thought - in which case you can use Control.Invoke
etc.
For other situations where there aren't UI controls or where you don't
want to go to the UI thread, you can easily set up your own message
queue.
See http://www.yoda.arachsys.com/csharp/...onitor.methods
for a very simple example of such a queue. (In practice you'd want a
way of stopping the queue etc.)
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Tell that to the COM team, where synchronization of single threaded
apartment objects relied on a hidden window and message pump :)
Of course, COM was providing the plumbing for environments like VB,
where thread management and synchronization functionality wasn't baked
into the runtime.
--
Scott http://www.OdeToCode.com
On Mon, 12 Jul 2004 14:02:34 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote: Nadav <Na***@discussions.microsoft.com> wrote: And why exactly the Win32 message queue should ONLY be used for UI Threads?????
Look at the docs for PostMessage, PostThreadMessage, GetMessage etc. They're full of references to UI concepts. To me, it's far cleaner to create a queue of messages which has *nothing* to do with UI, and use methods which also have nothing to do with UI (Monitor.Wait/Pulse etc).
Scott Allen <bitmask@[nospam].fred.net> wrote: Tell that to the COM team, where synchronization of single threaded apartment objects relied on a hidden window and message pump :)
Of course, COM was providing the plumbing for environments like VB, where thread management and synchronization functionality wasn't baked into the runtime.
Exactly. We have perfectly reasonable threading now with no need to
reference UI components at all.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon
the only UI concepts in Win32 threading is the WM_PAINT message - it is a
low priority message that is handled internally by the kernel, and is
dispatched when the queue is empty, and only after a flag has been set -
typically by the Invalidate API method. WM_TIMER is similar, but there is
no UI concern whatsoever. More appropriately, there are a lot of UI
concepts that are implemented using the Win32 Thread Message Queue. In the
absence of a window, you would use the PostThreadMessage, and specify the
thread id instead of the familar HWND. A much more acceptable approach
would be to create a message only window - hWndParent HWND set to
HWND_MESSAGE (still no UI stuff here), and then revert to the PostMesssage
that we are all so comfortable with, using the familar HWND.
A much stronger case for not using the Win32 thread message queue for
multithread comminucation and synchronization is the enormous overhead -
especially with the high number of kernel mode calls that are made - esp
PostMessage, GetMessage, and DispatchMessage - all of which can easily be
implemented using a simple queue object that exists entirely in the
application/process address space, and a CRITICAL_SECTION which requires a
kernel mode call only for the wait if the CS has been acquired - see Matt
Pietrek's excellent article Dec 2003...
That said, using the Win32 thread message queue for multithreading work is
quite acceptable - because it is available for use, well documented, and
very robust - albeit just not available in .Net yet (so the whole lot
quickly distills down to a moot point - much like discussing the rework of
the foreach statement).
regards
roy fine
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Nadav <Na***@discussions.microsoft.com> wrote: And why exactly the Win32 message queue should ONLY be used for UI Threads?????
Look at the docs for PostMessage, PostThreadMessage, GetMessage etc. They're full of references to UI concepts. To me, it's far cleaner to create a queue of messages which has *nothing* to do with UI, and use methods which also have nothing to do with UI (Monitor.Wait/Pulse etc).
-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Roy Fine <rl****@twt.obfuscate.net> wrote: the only UI concepts in Win32 threading is the WM_PAINT message
Really? In that case, why are the docs spattered with references to
windows? Sure, you can have invisible windows, but that's a hack, IMO -
there shouldn't be any need for it, or any reference to windows in
straight threading.
- it is a low priority message that is handled internally by the kernel, and is dispatched when the queue is empty, and only after a flag has been set - typically by the Invalidate API method. WM_TIMER is similar, but there is no UI concern whatsoever. More appropriately, there are a lot of UI concepts that are implemented using the Win32 Thread Message Queue. In the absence of a window, you would use the PostThreadMessage, and specify the thread id instead of the familar HWND. A much more acceptable approach would be to create a message only window - hWndParent HWND set to HWND_MESSAGE (still no UI stuff here), and then revert to the PostMesssage that we are all so comfortable with, using the familar HWND.
I don't think that *is* acceptable - because it's conflating the idea
of a window, which is a UI concept, even if it's then only used for
messages and is never made visible, and threading. Why *should* a
threading system use windows as the "more acceptable" approach? Does
that concept appear in other operating systems? (I genuinely don't know
the answer to that one.)
Even PostThreadMessage isn't UI-free - the docs talk about what desktop
the thread belongs to!
Furthermore, I regard the PostThreadMessage (and GetMessage etc) APIs
as somewhat non-OO. In my experience, it's cleaner to not know which
thread you're actually posting a message to, but only which *queue*
you're posting a message to - then it's very easy to add more threads
servicing the same queue. A message should also be a proper object,
rather than two integers with one of them split in half.
A much stronger case for not using the Win32 thread message queue for multithread comminucation and synchronization is the enormous overhead - especially with the high number of kernel mode calls that are made - esp PostMessage, GetMessage, and DispatchMessage - all of which can easily be implemented using a simple queue object that exists entirely in the application/process address space, and a CRITICAL_SECTION which requires a kernel mode call only for the wait if the CS has been acquired - see Matt Pietrek's excellent article Dec 2003...
Right - I'll look that out.
That said, using the Win32 thread message queue for multithreading work is quite acceptable - because it is available for use, well documented, and very robust - albeit just not available in .Net yet (so the whole lot quickly distills down to a moot point - much like discussing the rework of the foreach statement).
I don't think it's a moot point - I think there's significant design
discussion to be had here.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Jon Skeet [C# MVP]" I don't think that *is* acceptable - because it's conflating the idea of a window, which is a UI concept, even if it's then only used for messages and is never made visible, and threading. Why *should* a threading system use windows as the "more acceptable" approach? Does that concept appear in other operating systems? (I genuinely don't know the answer to that one.)
Even PostThreadMessage isn't UI-free - the docs talk about what desktop the thread belongs to!
here you go again with that bull-headed attitude - adopt an idea, and then
kill off all that cant accept it. The desktop is a security object not a
user interface object! reads the docs please - look at enum desktops. it
looks at all desktops in a specific windows stations. wndsta is not a UI
related object, and only ONE desktop in winsta0 is a UI related object. If
one takes your position to the extreme, then everything in the Windows
operating system is UI related, because is has the name Windows in it.
if you think a message-only window is a conflation of UI and non-UI, you
again miss the point. the message-only window has all of the things that we
are looking for - the message pump mechanism (GetMessage - DispatchMessage)
and it takes you one step above the thread - now you have process scope for
you message passing.
what other operating systems offer the threading model as Windows, you ask?
I don't think that should be allowed in here, as it just confuses the issue.
start another thread :)
Furthermore, I regard the PostThreadMessage (and GetMessage etc) APIs as somewhat non-OO. In my experience, it's cleaner to not know which thread you're actually posting a message to, but only which *queue* you're posting a message to - then it's very easy to add more threads servicing the same queue. A message should also be a proper object, rather than two integers with one of them split in half.
nice change of subject -- we are talking UI, and now you want to argue
vis-a-vis OO. but to argue that to know which thread versus which queue is
missing the point - you post to a thread id when using the thread message
queue - else you post to some other object, identified by some other handle
when using some other queuing mechanism - from an abstract, conceptual point
of view, they are soooo very close, the distinction is hard to see. A much stronger case for not using the Win32 thread message queue for multithread comminucation and synchronization is the enormous overhead - especially with the high number of kernel mode calls that are made - esp PostMessage, GetMessage, and DispatchMessage - all of which can easily
be implemented using a simple queue object that exists entirely in the application/process address space, and a CRITICAL_SECTION which requires
a kernel mode call only for the wait if the CS has been acquired - see
Matt Pietrek's excellent article Dec 2003...
Right - I'll look that out.
That said, using the Win32 thread message queue for multithreading work
is quite acceptable - because it is available for use, well documented, and very robust - albeit just not available in .Net yet (so the whole lot quickly distills down to a moot point - much like discussing the rework
of the foreach statement).
I don't think it's a moot point - I think there's significant design discussion to be had here.
again, you miss the point jon. arguing the merits of using the thread
message queue versus some other queuing mechanism IS a moot point in this
NG. in >Net, you do not have to consider the thread message queue.
regards
roy
-- Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet If replying to the group, please do not mail me too
Roy Fine <rl****@twt.obfuscate.net> wrote: I don't think that *is* acceptable - because it's conflating the idea of a window, which is a UI concept, even if it's then only used for messages and is never made visible, and threading. Why *should* a threading system use windows as the "more acceptable" approach? Does that concept appear in other operating systems? (I genuinely don't know the answer to that one.)
Even PostThreadMessage isn't UI-free - the docs talk about what desktop the thread belongs to! here you go again with that bull-headed attitude - adopt an idea, and then kill off all that cant accept it. The desktop is a security object not a user interface object! reads the docs please - look at enum desktops. it looks at all desktops in a specific windows stations. wndsta is not a UI related object, and only ONE desktop in winsta0 is a UI related object.
And that's just another annoying conflation, in my view. Why give a UI
desktop and a security object the same model? A UI desktop should no
doubt *have* a related security object, but conflating the two was a
mistake. Again, just my opinion.
Another way in which PostThreadMessage is UI-related is described in
the docs though: if the thread to which the message is posted is in a
modal loop, the message will get lost. That hardly seems like a good
idea - you need to know details about the thread you're posting a
message to in order to guarantee delivery. Just another reason to use
an API which posts a message to a queue rather than to a thread - then
any appropriate thread can pick up the message, whether that's by
pumping or some other mechanism.
If one takes your position to the extreme, then everything in the Windows operating system is UI related, because is has the name Windows in it.
There are plenty of APIs which don't refer to windows (or any other UI
element).
if you think a message-only window is a conflation of UI and non-UI, you again miss the point. the message-only window has all of the things that we are looking for - the message pump mechanism (GetMessage - DispatchMessage) and it takes you one step above the thread - now you have process scope for you message passing.
But the way things *should* be built, IMO, is to have a mechanism which
has nothing to do with the UI but which has message pumping (of a more
general kind, preferably of
what other operating systems offer the threading model as Windows, you ask? I don't think that should be allowed in here, as it just confuses the issue. start another thread :)
I don't think it confuses the issue at all - I think it shows that the
idea that threads and UI should always be related is probably not a
good one. Furthermore, I regard the PostThreadMessage (and GetMessage etc) APIs as somewhat non-OO. In my experience, it's cleaner to not know which thread you're actually posting a message to, but only which *queue* you're posting a message to - then it's very easy to add more threads servicing the same queue. A message should also be a proper object, rather than two integers with one of them split in half.
nice change of subject -- we are talking UI, and now you want to argue vis-a-vis OO.
It's not a change of subject at all. The OP wanted to know how to use
GetMessage because he wanted to do cross-thread communication. The non-
OO nature of Windows messages is another reason not to use
GetMessage/PostMessage and instead to use a more .NET-friendly way.
but to argue that to know which thread versus which queue is missing the point - you post to a thread id when using the thread message queue - else you post to some other object, identified by some other handle when using some other queuing mechanism - from an abstract, conceptual point of view, they are soooo very close, the distinction is hard to see.
And that handle has to be a window, right? If there's no window
*logically* needed, why use a mechanism which introduces it when
there's a perfectly good mechanism which *doesn't* introduce it? I don't think it's a moot point - I think there's significant design discussion to be had here.
again, you miss the point jon. arguing the merits of using the thread message queue versus some other queuing mechanism IS a moot point in this NG. in >Net, you do not have to consider the thread message queue.
The OP wants inter-thread communication. Whether to use P/Invoke to use
a Win32 message queue or whether to use a more OO, non-UI-related API
is far from a moot point. Both are feasible ways of working, but I'm
trying to give reasons why a message queue independent of the Win32
message queue is a good idea.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Michael Kalina |
last post by:
Because when I asked for comments on my site-design (Remember? My site,
your opinion!) some of you told me never to change anything on
font-sizes!
What do you guys think of that:...
|
by: JR |
last post by:
Hi folks,
How can I implement the following in C#?
while(AppExitFlag == false)
{
if(AppPausedFlag == true)
{
GetMessage();
// Process messages.
|
by: Ann Huxtable |
last post by:
Code placed after the statement Application.Run() is executed - is there
any reason why this is allowed (I can't see the point of permitting
statements after the "entry point" call) - akin maybe,...
|
by: Benny |
last post by:
I am creating a thread via "new Thread(new ThreadStart(p.ThreadProc))", is it
safe for ThreadProc to use GetMessage/TranslateMessage/DispatchMessage
instead of DoEvents?
What I would like to do...
|
by: |
last post by:
All,
I have a MFC Mixed mode dll which is working well. I am now tring to use a
regular C++ class from another DLL which has a method called GetMessage.
When I link I get 2 error messages:
...
|
by: Herman Jones |
last post by:
I found this statement in some sample code. It seems to be syntactically
correct. What do the brackets around "String" mean?
Dim sWork As = "Some number of characters"
|
by: salvadorvp |
last post by:
Hi, I have the following code that gives me this odd error message at
a line of code inside the PEAR libraries:
"Fatal error: Call to undefined function:
MDB2_Driver_mssql::getMessage(). in...
|
by: schm4704 |
last post by:
Hi,
I was wondering if there is a way to make the SQLException of the new
JCC JDBC driver behave and get a decent message out of
SQLException.getMessage().
Though I *do* know how to get the...
|
by: dmjpro |
last post by:
Please make me understand ... why Exception.getMessage() returns null.
In which situation it happens, please explain me.
Debasis Jana
|
by: CloudSolutions |
last post by:
Introduction:
For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
|
by: taylorcarr |
last post by:
A Canon printer is a smart device known for being advanced, efficient, and reliable. It is designed for home, office, and hybrid workspace use and can also be used for a variety of purposes. However,...
|
by: aa123db |
last post by:
Variable and constants
Use var or let for variables and const fror constants.
Var foo ='bar';
Let foo ='bar';const baz ='bar';
Functions
function $name$ ($parameters$) {
}
...
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
| |