WindowsFormsSynchronizationContext.Send: how does the delegateprovided to this method interact with

[eugen_nw]

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

 

[eugen_nw]

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.

 

[eugen_nw]

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 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.