We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. (Last updated on: November 16, 2018).
Unfortunately, activation email could not send to your email. Please try again.
Syncfusion Feedback

Is BeginUpdate() the answer to the problem?

Thread ID:





11899 Mar 17,2004 07:24 PM UTC Mar 18,2004 12:26 AM UTC WinForms 6
Tags: GridControl
Administrator [Syncfusion]
Asked On March 17, 2004 07:24 PM UTC

In my previous post I asked how to know when the grid is done rendering the CellValue in the GridStyleInfo that you fill up during a QueryCellInfo.. I noticed the BeginUpdate() method on the grid and it seems it could solve the problem in reverse: by calling it on the GridControl before making an update to the virtual data source, the grid will freeze its repaints and thus the changes made during a series of QueryCellInfo calls. Once the EndUpdate() is called, the paints are made. This would seem to have the desired effect of giving the producer thread a chance to update the virtual data source without corrupting it as the grid paints its contents. However I''m unsure of a few things. What happens if the producer thread hangs too long, and the user moves their hides and then unhides their window, they then have an unpainted grid? And lastly, once EndUpdate is called, are the repaints only going to happen to the cells which were refreshed? Because if the entire visible range were repainted, that would defeat the purpose of only refreshing a certain range, and the performance advantages that go with it.

Administrator [Syncfusion]
Replied On March 17, 2004 08:14 PM UTC

"thus the changes made during a series of QueryCellInfo calls". There are no changes made through QueryCellInfo. QueryCellInfo just requests the values from your datasource. This happens anytime the grid needs a value (like to draw it, or if you have code that requests a value for some reason). So, when the grid needs to draw cell 1,1, it fires QueryCellInfo to get cell 1,1. If it does not draw cell 1,1, it does not necessary fire QueryCellinfo. So, calling grid.BeginUpdate will likely prevent QueryCellInfo from being fired. QueryCellInfo is sort of a JIT event. It is fired just in time to get the data when the grid needs it. It does not push any data back to your data source. SaveCellInfo is teh event that is fired when data has changed and needs to get put back to the datasource. So, if you start editing a cell, the grid fires aqueryCellInfo to get the current value to populate the control that is used for editing, maybe a TextBox cell. Once you have finished editing this textbox cell to modify the value, and you indicate you are finished by leaving the cell, the grid will fire SaveCellInfo passing e.Style that represents the changed value from the cell control (TextBox). It is at this point, the data is saved back to your datasource.

Administrator [Syncfusion]
Replied On March 17, 2004 08:20 PM UTC

Clay, I understand the way SaveCellInfo works, and thanks for pointing out that calling BeginUpdate actually prevents QueryCellInfo from being fired. All that said, how do I know that the grid is *done* rendering/drawing the value that I stored in a GridCellInfo (by way of a previous QueryCellInfo call)? Don''t I need to know this in order to know when its safe to then update the data that CellValue now points to, or risk the grid drawing a corrupted value?

Administrator [Syncfusion]
Replied On March 17, 2004 08:28 PM UTC

Maybe you could derive the grid, override OnPaint, and call the base class. This way you can mark exactly before and after the painting.

Administrator [Syncfusion]
Replied On March 17, 2004 09:54 PM UTC

Interesting. Your response leads me to ask for a clarification. When you set a property on the GridStyleInfo instance inside QueryCellInfo, does that synchronously cause the cell to paint? In other words, when I call set {..} on the GridStyleInfo''s CellValue and the call returns, has the the grid finished painting the cell for that property? If that is the case then I can know for sure that after the CellValue property has been set I can be free to modify the data was just drawn. That would make sense especially with regard to the use of BeginUpdate(), since that would help when setting multiple properties on the GridStyleInfo instance.

Administrator [Syncfusion]
Replied On March 17, 2004 11:43 PM UTC

OnPaint (or actually, a several methods removed from OnPaint, but you can think of it as OnPaint), calls OnQueryCellInfo which fires the event. In QueryCellInfo, you set e.Style, and QueryCellInfo returns the value of e.Style. The calling routine uses e.Style to draw the cell. These actions are synchronous. So, the grid has not finished drawing within QueryCellInfo.

Administrator [Syncfusion]
Replied On March 18, 2004 12:26 AM UTC

Ok I think I''m starting to follow you here. So basically the drawing continues after QueryCellInfo returns, and therefore its possible that there is a race condition in that the UI thread (that is querying for the cell data and then drawing it) can be intercepted by a producer thread that might modify the data being drawn before the data was rendered? So how do folks suggest getting around this possible race condition when working with frequently updated realtime data sources? You mentioned overriding one of the paint methods and then using that to declare that the data being drawn is no longer being used by the grid control. What does everyone else do?


This post will be permanently deleted. Are you sure you want to continue?

Sorry, An error occured while processing your request. Please try again later.

Warning Icon You are using an outdated version of Internet Explorer that may not display all features of this and other websites. Upgrade to Internet Explorer 8 or newer for a better experience.Close Icon