Hi,
I have an MDI application, and one of the MDI Views contains an Ultragrid. Sometimes, when opening this view, I get the exception below. It does not always happen. Also, if we just click "Continue" in the exception handling window, the view appears to load correctly and work fine. This exception appears to show up before any data (as in cell values) has been loaded into the grid. We attach to a data source to get our columns, but not for data. We have a number of grids in our application and have only seen this bug in this one grid. Does anyone have any ideas what could be causing the crash, how to fix it, or at least where to add a try/catch to handle it? Any help is appreciated.
Here's the Exception Details:
System.ArithmeticException: Overflow or underflow in the arithmetic operation. at Infragistics.Win.Layout.GridBagLayoutManager.GridBagHelper(ILayoutContainer container, Object containerContext, Boolean layoutContainer, Boolean returnItemDimensions) at Infragistics.Win.Layout.GridBagLayoutManager.GetLayoutItemDimensions(ILayoutContainer container, Object containerContext) at Infragistics.Win.UltraWinGrid.UltraGridBand.VerifyRowLayoutCache() at Infragistics.Win.UltraWinGrid.UltraGridBand.GetAllOrderedHeaders() at Infragistics.Win.UltraWinGrid.UltraGridBand.CalculateBandMetrics(UltraGridBand priorBand) at Infragistics.Win.UltraWinGrid.BandsCollection.CalculateBandMetrics(Int32 pass) at Infragistics.Win.UltraWinGrid.BandsCollection.CalculateBandMetrics() at Infragistics.Win.UltraWinGrid.ColScrollRegionsCollection.InitializeMetricsHelper() at Infragistics.Win.UltraWinGrid.ColScrollRegionsCollection.InitializeMetrics() at Infragistics.Win.UltraWinGrid.UltraGridLayout.ApplyLoadedBands() at Infragistics.Win.UltraWinGrid.UltraGridLayout.ListManagerUpdated(BindingManagerBase bindingManager) at Infragistics.Win.UltraWinGrid.UltraGridLayout.ListManagerUpdated() at Infragistics.Win.UltraWinGrid.UltraGridBase.Set_ListManager(Object newDataSource, String newDataMember) at Infragistics.Win.UltraWinGrid.UltraGridBase.VerifyDataSourceAttached() at Infragistics.Win.UltraWinGrid.UltraGridBase.OnCreateControl() at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible) at System.Windows.Forms.Control.CreateControl() at System.Windows.Forms.Control.WmShowWindow(Message& m) at System.Windows.Forms.Control.WndProc(Message& m) at System.Windows.Forms.ScrollableControl.WndProc(Message& m) at System.Windows.Forms.ContainerControl.WndProc(Message& m) at System.Windows.Forms.Form.WmShowWindow(Message& m) at System.Windows.Forms.Form.WndProc(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m) at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m) at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
Thanks,
~Karen
Hi Karen,
It looks like the exception is occurring while the grid is trying to lay out the column headers of the grid using RowLayouts.
So my guess is that something really unusual is causing it, like maybe the grid control has a very large or very small size at this point, and some measurement calculation is coming out either way too high or way too low.
But I'm afraid without being able to reproduce the issue, there's very little we can do to try to debug it. You say it doesn't happen all the time - but can you reproduce the issue reliably? If you do the same steps 10 times, does it happen at least once? Or is it completely random and unpredictable?
Hi Mike,
It's one of those really fun bugs where the customer runs into it all the time, and I can't reproduce it with any consistency at all. I will open the view 50 times without seeing it and then maybe get it to happen once. So for me it's currently completely random and unpredicable.
I was wondering if it was a sizing issue as well. I will try and get some more details from our customer to see if i can reproduce their environment a little more. They are running on tablet computers so their resolution/screen size/font settings may be very different from mine.
Also, I am using the graphic row layout manager to design my grid's layout. This is the only grid where i use this. The others have the layout set up in the designer, but by using Groups and Levels. In case this doesn't make sense, I'm talking about Clicking the "Start" button on the grid in the Designer, then Going to Band and Column Settings > Band (0) > Column Arrangement Overview and selecting "Use Row Layout" vs "Use Groups and Levels". Is the Row Layout less dependable than Groups and Levels?
Thanks for the help,
kcrab2000 said:can you tell me where i could put in a try/catch that will catch this error?
The exception is occurring in the CreateControl method when the form is being displayed. So the only way I can see to trap it would be to put a try...catch around the form.Show method.
I have created the following support ticket for you: CAS-53503-YGMKTY. Please send me a sample project and I will research your question further. And will able to provide you more accurate suggestions.
Regards,
Stefaniya
I have contacted my customers and gotten their font/display settings. I still can't reproduce the crash using those settings.
Since this crash does not seem to be causing any ill effects if we just continue through it, can you tell me where i could put in a try/catch that will catch this error?
Let me know if there is something I can help you with.
kcrab2000 said: Is the Row Layout less dependable than Groups and Levels?
I certainly would not say that. But RowLayouts are a lot more complex.
In order to get an overfllow/underflow, it means that some mathematically calcuations is resulting in a value that is exceeding the limits of the data type. So in order for this to happen, some calculations is coming out with a height or a width of a column header that is invalid because it is either higher than int.MaxValue or lower than int.MinValue. There are ridiculously large (or small) numbers, of course, so there's really no way that should ever happen.