WindowsFormsSynchronizationContext.Send: how does the delegate provided to this method interact with the control's message pump?   

I did look under the hood and this method is calling
Control.Invoke().  Digging deeper down I've stopped at the
RuntimeMethodHandle._InvokeMethodFast() method whose code I cannot
find.

I know that the delegates invoked via Control.BeginInvoke() will use
the window's message pump to send and retrieve the delegate and its
arguments, so the control/form will not react to Windows messages
while it is executing the delegate.  That is the behavior I want to
have as well when the delegate passed to
WindowsFormsSynchronizationContext.Send() executes.

For a bit of a background, I want to have this behavior in order to
make sure that a grid control will not repaint itself while I'm re-
populating the DataTable it is bound to.  If you have other
suggestions on how to ensure that the grid will not read from the
DataTable at the same time a worker thread reloads it, please send
them my way.


Thanks much,  eugen

date: Wed, 13 Aug 2008 17:17:13 -0700 (PDT)   author:   eugen_nw

Re: WindowsFormsSynchronizationContext.Send: how does the delegate provided to this method interact with the control's message pump?   

I wasn't very clear in the last paragraph of my original post: I'm
using a different thread to run the query that populates the DataTable
the grid is bound to and bad things happen if the grid in the UI
thread tries to read from the DataTable at the same time the
DataAdapter.Fill method populates it on the worker thread.

date: Wed, 13 Aug 2008 17:54:49 -0700 (PDT)   author:   eugen_nw

Re: WindowsFormsSynchronizationContext.Send: how does the delegate provided to this method interact with the control's message pump?   

On Wed, 13 Aug 2008 17:17:13 -0700, eugen_nw  
 wrote:

> I did look under the hood and this method is calling
> Control.Invoke().  Digging deeper down I've stopped at the
> RuntimeMethodHandle._InvokeMethodFast() method whose code I cannot
> find.
>
> I know that the delegates invoked via Control.BeginInvoke() will use
> the window's message pump to send and retrieve the delegate and its
> arguments, so the control/form will not react to Windows messages
> while it is executing the delegate.  That is the behavior I want to
> have as well when the delegate passed to
> WindowsFormsSynchronizationContext.Send() executes.
>
> For a bit of a background, I want to have this behavior in order to
> make sure that a grid control will not repaint itself while I'm re-
> populating the DataTable it is bound to.  If you have other
> suggestions on how to ensure that the grid will not read from the
> DataTable at the same time a worker thread reloads it, please send
> them my way.

Well, the easiest way to block the GUI is to not run your code on the  
worker thread in the first place.  Just repopulate the DataTable from the  
main GUI thread, and that will stop your entire GUI from working, avoiding  
any chance that the user might see updates while you're changing the  
DataTable.

Personally, I'm not a big fan of blocking the GUI.  I don't really  
understand why you don't want updates while the DataTable is being  
repopulated.  But why not just temporarily set the DataSource to null  
while you update the DataTable and then set it back to your DataTable when  
you're done?  You could even put up a little "Reloading Data" TextBox over  
the DataGridView control while the update happens.

Whatever your goals, I'm pretty sure you're barking up the wrong tree.   
All this talk of "BeginInvoke()" and "SynchronizationContext", that stuff  
isn't for blocking threads.  It's for helping threads keep running.  That  
a method invoked using Control.Invoke() or Control.BeginInvoke() has the  
ability to block the GUI thread is a side-effect and in fact one would  
typically take pains to be careful about those methods to make sure they  
_don't_ block the GUI thread for very long.

Pete

date: Wed, 13 Aug 2008 18:29:11 -0700   author:   Peter Duniho

Re: WindowsFormsSynchronizationContext.Send: how does the delegate provided to this method interact with the control's message pump?   

Hi Peter,

Thanks for your reply.  Please see some notes inline.  By the way, do
you happen to know the answer to the question in the subject?

eugen

>
> Well, the easiest way to block the GUI is to not run your code on the  
> worker thread in the first place.  Just repopulate the DataTable from the  
> main GUI thread, and that will stop your entire GUI from working, avoiding  
> any chance that the user might see updates while you're changing the  
> DataTable.

[eugen]  "Been there, done that".  Some queries may take long to
complete and the user is left with a frozen screen that [s]he cannot
use even to activate a menu or navigate to another MDI view.  The
worker threads run the queries and then merge the results in the
DataTable the controls are bound to.  It is the merging of the data
only that I will execute on the UI thread.

> I don't really  
> understand why you don't want updates while the DataTable is being  
> repopulated.  

[eugen]  The application crashes if a grid reads from a DataTable at
the same time the worker thread is busy clearing and repopulating it.
The grid will read the DataTable if it happens that the user sorts or
groups the grid or hits the screen's Refresh button.

> But why not just temporarily set the DataSource to null  
> while you update the DataTable and then set it back to your DataTable when  
> you're done?

[eugen]  "Been there, done that" too.  Some grids do not handle this
well, for example those that have grouping in effect.

date: Thu, 14 Aug 2008 12:40:38 -0700 (PDT)   author:   eugen_nw

Re: WindowsFormsSynchronizationContext.Send: how does the delegate provided to this method interact with the control's message pump?   

On Thu, 14 Aug 2008 12:40:38 -0700, eugen_nw  
 wrote:

> Hi Peter,
>
> Thanks for your reply.  Please see some notes inline.  By the way, do
> you happen to know the answer to the question in the subject?

No, I don't.  But I really don't think you need to know.  If your goal is  
to block the GUI until the update is done, then just run the update on the  
GUI thread.

Pete

date: Thu, 14 Aug 2008 16:58:12 -0700   author:   Peter Duniho