Re: What is the C# equivalent of GetMessage ????

• Previous message: James Dean: "Question about 8bit colour"
• In reply to: Roy Fine: "Re: What is the C# equivalent of GetMessage ????"
• Messages sorted by: [ date ] [ thread ]

Date: Wed, 14 Jul 2004 09:33:50 +0100

Roy Fine <rlfine@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 - <skeet@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

• Previous message: James Dean: "Question about 8bit colour"
• In reply to: Roy Fine: "Re: What is the C# equivalent of GetMessage ????"
• Messages sorted by: [ date ] [ thread ]