The reason that you can't (safely) call arbitrary methods of the form from within another thread is that doing so could only work reliably if every bit of WinForms code -- and every bit of your application that ran as a result of the user's interaction with the UI -- were written to be both 100% thread-safe and re-entrant. That would have imposed rather significant overhead, both in code complexity and in performance. AFAIK, there is no GUI framework for any environment (though I'm only familiar with Windows GUI frameworks) that implements thread-safe re-entrant code for the main UI thread (and thereby imposes the same requirements on application code), and there are many such frameworks.
You could go ahead and call form.SetSomething if you have no concern that the form might be in the middle of some operation -- perhaps caused by the user -- that might cause either SetSomething or the active operation to work incorrectly due to lack of synchronization. The form.Invoke model is rather elegant compared to -- for example -- constructing a raw Windows message (with an application-custom message ID and message format) and calling PostMessage, having modified the window procedure for the form to recognize the message and call the right routine in response. (Most programmers could not take advantage of multi-threading at all before .NET, because of the complexities involved.) If you think of your "worker thread" as being code which could someday be running on a different computer, or inside a different "virtual machine" within the same computer (when the full "utility computing" model has been implemented), the idea of the worker thread saying "please run this code in the form's environment" should make more sense. The reason you can't have a modal message box without another message loop is that the user's actions against a displayed window can't go to that window unless there's a message loop directing messages to that window -- no other message loop will direct messages to a window that it didn't create. (Anyway, does it really make sense to have the worker thread stop dead with a message box while the user is interacting with the main UI? I don't think so. So the main UI should display the message box.) At 09:11 PM 2/22/2004, Jade Burton wrote >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 have to call some hokey >form.Invoke(SetSomeControlMethod, blah) in order to update something on the >form from within a worker thread? > >When I first saw .NET I had hoped that a cleaner model had been adopted by >WinForms, but alas I was disappointed to see it's but another Windows >wrapper. > >I'm not sure there's a clean alternative to having a message pump drive the >UI (maybe there is?), but there *must* be a cleaner way than the current >segregated STA-MTA ideology which has weasled its way into .NET? For >example, why can't I just call form.SetSomeControlMethod and have it update >inline, without any windows messages being sent? (And why can't I create a >modal dialog from within a worker that simply blocks until the user clicks >OK, rather than using another message loop etc?) > >Or are we stuck with what I would regard as a system that requires the >programmer to write (and - ugh - think about) "non-business logic" 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 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-blocking operations >on your main UI thread. This rule goes right up there alongside "thread >that creates the window services the window". > >(By "it is difficult to free the main thread" I assume you mean your main >UI thread is performing some long-blocking operation -- like socket i/o, or >calculating pi to 3000 decimal places, or what have you. Don't do that.) > >-Shawn >http://www.windojitsu.com/ > >On Fri, 20 Feb 2004 13:35:57 -0500, Aman Jain <[EMAIL PROTECTED]> wrote: > >>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: thread that creates the window services the window) >>using >> >> >> private void OnAlarmMessageReceived(AlarmMessage msg) >> { >> if(InvokeRequired) // Pass on to GUI thread >> { >> BeginInvoke(new >>AlarmMsgReceivedHandler(OnAlarmMessageReceived), new Object[] { msg } ); >> return; >> } >> // whatever needs to be done >> } >> >>This works fine but with the requirement that the main thread is free. >>Now, there are many situations where it is difficult to free the main >>thread but there are errors that need to be displayed. >>What I need is a UI thread that remains alive during the application >>lifetime on which I can create and service the alarm window. In the >>managed world (using C#) , how do we create a thread with a message pump >>as opposed to a worker thread ? >> >>Any help is greatly appreciated. >> >>Thanks in advance, >>Aman J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentor® http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
