I'm trying to wrap my head around the "asyncronous-ness" of the WinGrid (putting off actions by marking things dirty, etc) and was confused by a particular method.
It is my understanding that nothing internal in the WinGrid is done on any thread other than the UI thread, which seems contradicted by the design of the SyncRows() method in Infragistics.Win.UltraWinGrid.RowsCollection.
First, there is a boolean member in the class to track when the SyncRows method is being executed (inSyncRows) to prevent execution of the method if the method is already executing. This purpose is explained by a lengthy comment about timer ticks overlapping, which also didn't make any sense (if all the timers are form timers then it should be a single file line of messages on the pump to be processed...you can't have overlapping execution).
Second, a lock statement is used in the middle of the method (this is the only place I saw a lock statement used in the entire assembly). There is no other reason for a lock statement other than single thread restriction in a multi threaded application.
Is there some kind of black magic going on here or is this just unnecessary legacy code?
Thanks!
Hi,
Regarding the Timer, this code is to work around a bug in the WinForms Timer object.
What happens is that when you stop any WinForms Timer, the DotNet Framework uses a PeekMessage to go ahead and look for any other Timers that are running and it fires off the Tick event on those timers. It doesn't happen on another thread, but if anything inside the code of the SyncRows methods stops a Timer by setting Enabled to false, it causes any other active Timers to fire off a Tick event synchronously, which can then cause the SyncRows event to get called again.
So that's the reason for the anti-recursion flag there.
I'm not sure why there's a 'lock' in this code. My best guess is that it was put in there simply as a precaution. It doesn't hurt anything to do that, but since you really cannot mix DataBinding and multiple threads, anyway, that lock probably doesn't have much of an effect.
Thanks Mike! That's an interesting note about the Timer class, I'll have to look into that.
For documentation purposes, here's a link to the Timer.Stop() issue on Connect (from 2005):
http://connect.microsoft.com/VisualStudio/feedback/details/116928/stopping-a-windows-forms-timer-can-cause-other-timers-tick-events-to-fire-causing-unexpected-re-entrancy
It is marked as fixed, however it appears the "fix" was to document the behavior in MSDN:
http://msdn.microsoft.com/en-us/library/system.windows.forms.timer.stop.aspx