Hi,
I am tring to pass messages between threads, using the good old C++ I would call the GetMessage/PostThreadMessa ge 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  13458 
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***@discussi ons.microsoft.c om> wrote in
news:37******** *************** ***********@mic rosoft.com... Hi,
I am tring to pass messages between threads, using the good old C++ I
would call the GetMessage/PostThreadMessa ge 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, PostThreadMessa ge, ... ).
--
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***@discussi ons.microsoft.c om> wrote in
news:37******** *************** ***********@mic rosoft.com... Hi,
I am tring to pass messages between threads, using the good old C++ I
would call the GetMessage/PostThreadMessa ge 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***@discussi ons.microsoft.c om> 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, PostThreadMessa ge,
... ).
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.co m> 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.co m> wrote: Nadav <Na***@discussi ons.microsoft.c om> wrote: And why exactly the Win32 message queue should ONLY be used for UI
Threads?????
Look at the docs for PostMessage, PostThreadMessa ge, 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.co m> 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 PostThreadMessa ge, 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_SECTIO N 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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... Nadav <Na***@discussi ons.microsoft.c om> wrote: And why exactly the Win32 message queue should ONLY be used for UI
Threads?????
Look at the docs for PostMessage, PostThreadMessa ge, 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.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Roy Fine <rl****@twt.obf uscate.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 PostThreadMessa ge, 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 PostThreadMessa ge isn't UI-free - the docs talk about what desktop
the thread belongs to!
Furthermore, I regard the PostThreadMessa ge (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_SECTIO N 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.co m> 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 PostThreadMessa ge 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 PostThreadMessa ge (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_SECTIO N 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.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Roy Fine <rl****@twt.obf uscate.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 PostThreadMessa ge 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 PostThreadMessa ge 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 PostThreadMessa ge (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.co m> 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: http://www.clagnut.com/blog/348/
I hope that's going to be a good discussion!
Michael
|
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, to allowing
statements after "main" in C/C++
|
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 is to have messages posted to ThreadProc and have
ThreadProc process those messages (similar to using PostThreadMessage in
unmanaged code).
Thanks.
|
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:
MyClass.obj : error LNK2028: unresolved token (0A00074C) "public: class
CMessage * __thiscall CTransmitMessage::GetMessage(int)"
(?GetMessage@CTransmitMessage@DSS@@$$FQAEPAVCMessage@2@H@Z) referenced in
| | |
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 C:\php\PEAR\lib\MDB2.php on line
1921"
My code is a simple submit processing form for a login page:
<?php
|
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 message via DB2Diagnosable, DB2Sqlca
etc., the problem is that we're using the SQuirreL V2.5 SQL client for
teaching, in which error messages are obtained from
Throwable.getMessage() in a pretty much hardwired fashion which would
|
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: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
| | |
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
