SendMessage only calls the target window's procedure directly if you
call it from the UI thread. The Win32 documentation says that if you
send a message from some other thread, the message will only be
processed when the UI thread executes message retrieval code (i.e. its
message pump runs). It
Inline
At 07:22 AM 3/2/2004, Griffiths, Ian wrote (in part)
SendMessage only calls the target window's procedure directly if you
call it from the UI thread. The Win32 documentation says that if you
send a message from some other thread, the message will only be
processed when the UI thread
I think either you're over-analyzing this, or the problem is in fact
much
bigger than MVC. :)
Over-analysis: personality-flaw or occupational hazard? :)
John.
===
This list is hosted by DevelopMentor® http://www.develop.com
Some .NET courses you may be
If the UI never accesses the model directly (which would require
locking
to avoid possibly getting inconsistent data if the model is in the
process
of being updated), but only sends requests (via BeginInvoke) to the
model
thread for information, does that solve the problem?
I'm not sure that
: [ADVANCED-DOTNET] Thread with message pump (UI thread)
If the UI never accesses the model directly (which would require
locking
to avoid possibly getting inconsistent data if the model is in the
process
of being updated), but only sends requests (via BeginInvoke) to the
model
thread
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Yes, Control.Invoke uses the message pump. The message pump is the queue
you speak of. I'm guessing the mechanism uses a PostMessage with a
WM_USER
+ x.
- Original Message -
From: John Elliot
Or you may want to take a look at Microsofts asynchronous application
block
I've spent an hour or two sort of looking through the code for this, but
haven't got too heavily involved with it. I guess the reason I didn't
get to stuck into it is that I don't really want asynchronous
processing. I
Message-
From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED-
[EMAIL PROTECTED] On Behalf Of John Davis
Sent: 01 March 2004 11:48
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Yes, Control.Invoke uses the message pump. The message pump
: 01 March 2004 19:18
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
I think they both use PostMessage and Control.Invoke waits on event.
This difference is *almost* never makes a difference.
Dmitriy
Richard Blewett wrote:
Control.Invoke uses
If the UI never accesses the model directly (which would require locking to avoid
possibly getting inconsistent data if the model is in the process of being updated),
but only sends requests (via BeginInvoke) to the model thread for information, does
that solve the problem?
The UI thread will
Hi John,
I think either you're over-analyzing this, or the problem is in fact much
bigger than MVC. :)
Let's forget about MVC for a moment, and consider a much more common
scenario: WM_PAINT.
Do the View objects know how to render themselves, without asking anything
of the Document? Probably
2004 14:28
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
I'm not certain that I understand your situation completely, but I
don't
see any issues that wouldn't be handled by using BeginInvoke rather
than
Invoke. That will let both UI and process
I'm not certain that I understand your situation completely, but I
don't
see any issues that wouldn't be handled by using BeginInvoke rather
than
Invoke. That will let both UI and process threads proceed without
waiting
on the other.
I was implying that I would use BeginInvoke, so that each
of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Shawn A. Van
Ness
Sent: Tuesday, 24 February 2004 7:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Jade, I feel your pain. But I think if you really followed it through -- as
you say, starting from
Oh, and the Tablet PC's Ink API fires some events on background
threads...
Go figure, eh?
Firing events from background threads for consumption in the UI is the
hardest problem (for me) that I face at the moment.
If I have a long running process that needs to invoke events that the UI
has
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Shawn A. Van
Ness
Sent: Tuesday, 24 February 2004 7:20 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Jade, I feel your pain. But I think if you
Jade Burton wrote:
wouldn't it be great if the UI thread wasn't tagged as STA,
but rather that it was just like any old thread? This would
mean you still have a single thread dispatching events to event
handers, but your window objects would instead be written to be 100%
threadsafe and, for
There can be no final points in this discussion!
From a practical perspective, I most heartily disagree. Single-threading is a much
simpler model to work in, and unless the language / environment makes it 100%
transparent that we're not single-threaded we'll have so many bugs it simply isn't
Ness
Sent: Saturday, 21 February 2004 10:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Call Application.Run (or even Application.DoEvents) do establish a message
queue for your secondary thread.
A better answer: You should not be performing any long
plumbing code...
Jade Burton
-Original Message-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of
Shawn A. Van Ness
Sent: Saturday, 21 February 2004 10:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI
You should not be performing any long-blocking operations on your main UI
thread.
Some articles on this topic that I have found helpful are:
http://msdn.microsoft.com/msdnmag/issues/03/02/Multithreading/default.aspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/htm
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
As a sidebar to the topic of threads and message pumps, am I the *only*
person in the world who wishes there was greater *cohesion* and
*transparency* between WinForms' and worker threads?
Why, in 2004, do programmers
-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED] Behalf Of Shawn A. Van
Ness
Sent: Saturday, 21 February 2004 10:48 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Thread with message pump (UI thread)
Call Application.Run (or even Application.DoEvents) do
Call Application.Run (or even Application.DoEvents) do establish a message
queue for your secondary thread.
A better answer: You should not be performing any long-blocking operations
on your main UI thread. This rule goes right up there alongside thread
that creates the window services the
Hi Everybody,
The alarm manager in my Windows Forms application has a alarm control
(User control) that is used to display errors.
This is created on the Main thread. Whenever any calls are made on this
control to display errors, we take care to switch to the Main thread
(windows principle:
Aman,
In the
managed world (using C#) , how do we create a thread with a message pump
as opposed to a worker thread ?
You call Application.Run() from that thread.
Mattias
--
Mattias Sjögren
[EMAIL PROTECTED]
===
This list is hosted by DevelopMentor®
26 matches
Mail list logo
