Exceptions thrown in virtual grid

[Giles Thomas]

Hi,

We have an application that uses the Essential Grid in "Virtual" mode. We have written an "Insert row" function to allow our users to insert a row above the currently selected one; this changes our internal data model appropriately and then informs the grid that the data has changed by calling its "Refresh" method.

Sometimes, but not always, once we have done this, the grid starts printing out stack traces every time we try to edit a cell; an example:

catched at Syncfusion.Windows.Forms.Grid.GridModel.SetCellInfo(Int32 rowIndex, Int32 colIndex, GridStyleInfo style, StyleModifyType modifyType, Boolean dontRaiseSaveCellInfoEvent, Boolean copyReferenceOnly) in :line 0
catched at Syncfusion.Windows.Forms.Grid.GridCurrentCell.ConfirmChanges(Boolean closeDropDown) in :line 0
catched at Syncfusion.Windows.Forms.Grid.GridCurrentCell.Deactivate(Boolean discardChanges) in :line 0
catched at Syncfusion.Windows.Forms.ScrollControl.RaiseCancelMouseEvent(MouseEventArgs e, CancelMouseDelegate d) in :line 0

As far as we can tell, none of our own code is being called in the chain that leads to these exceptions being thrown/"catched" - but perhaps something that we are doing is leaving the grid in an inconsistent state?

Any help would be much appreciated.

Giles

[Administrator]

Hi Giles, Sorry, I am not able to reproduce the mentioned issue. Attached is a sample that works fine with out any exception in the mentioned scenario. Can please reproduce the issue in the attached sample and sent it back so that we can get back with a solution at the earliest? Thanks, Calvin.

VirtGrid.zip

[Anonymous]

Hi Calvin

We''ve managed to characterise the problem a bit better -- and even, we think, fix it -- but we''re still not quite sure what was causing it in the first place.

First of all, we can fix the problem by always handling the SaveCellFormattedText event -- previously, we were not doing so when the cell was a row/col header.

However, I don''t understand why the grid thinks it has any changes to save -- all we had to do to trigger the problem was to choose a calculation-intensive command from the context menu on the grid (which we display in a MouseDown handler) and click another cell before calculation was complete. Could we be doing anything in the MouseDown handler to cause the problem, do you think?

Thanks for your help
William

[Administrator]

Hi William,

I am not able reproduce the issue even after handling the MouseDown event and having an intensive calculation, and not sure what would have caused the issue. Can you please modify the previous sample to cause the issue and sent back?

Thanks,
Calvin.

[Anonymous]

Hi Calvin

My bad, I''m afraid -- it turns out that we were calling the grid from another thread, without always wrapping the call in an Invoke.

However, we''ve been depending on System.Windows.Forms.Control.CheckForIllegalCrossThreadCalls to alert us to problems of this nature, and it seems that this setting does not apply to your product.

Is there a setting somehwere that will enable this checking for Syncfusion components as well?