Line of Code in AfterCellUpdate event.

if

((double)e.Cell.Value < 0)

System.InvalidCastException was unhandled by user code
  Message="Specified cast is not valid."
  Source="UGTest"
  StackTrace:
       at Mitsic.frmcEquipment.ugEquip_AfterCellUpdate(Object sender, CellEventArgs e) in C:\Documents and Settings\rand\My Documents\Visual Studio 2008\Projects\UGTest\UGTest\frmcUgTestt.cs:line 7532
       at Infragistics.Win.UltraWinGrid.UltraGrid.OnAfterCellUpdate(CellEventArgs e)
       at Infragistics.Win.UltraWinGrid.UltraGrid.FireEvent(GridEventIds id, EventArgs e)
       at Infragistics.Win.UltraWinGrid.UltraGridCell.SetValueInternal(Object value, Boolean suppressErrorMessagePrompt, Boolean fireInitializeRow, Boolean throwExceptionOnError, Boolean fireDataChanged)
       at Infragistics.Win.UltraWinGrid.UltraGridCell.SetValueInternal(Object value, Boolean suppressErrorMessagePrompt, Boolean fireInitializeRow, Boolean throwExceptionOnError)
       at Infragistics.Win.UltraWinGrid.UltraGridCell.SetValueInternal(Object value, Boolean suppressErrorMessagePrompt, Boolean fireInitializeRow)
       at Infragistics.Win.UltraWinGrid.UltraGridCell.CommitEditValue(Boolean& stayInEdit, Boolean fireDataError, Boolean forceDontThrowException, Boolean dontStoreInUndoHistory)
  InnerException:

melegant said:

This whole converstaion has left me truly annoyed and ready to just rip out Infragistics and go with DevExpress. And when we make the move to Silverlight, I should go with who based on this conversation...

Well, I'm very sorry you feel that way. Perhaps it's sometimes hard to judge tone when reading text. But to me, it feels like I have been bending over backwards to try to help you out here, even though almost nothing about this discussion has anything to do with the WinGrid or any Infragistics products.

melegant said:

The quick and simple answer would have been:

When using a SQL Float the UltraGrid will translate as System.Double, whereas any other SQL Floating type # will come across as System.Decimal.

You started off in your original post asking why you are getting an error when you tried to cast a boxed decimal to a double in one operation. So you were obviously aware of the fact that some of your values were decimals. So I tried to explain why the error was occurring, since that is what you asked. 

But just to be clear, the UltraGrid doesn't translate anything. It's not the grid that determines the data types of the fields. The grid simply creates columns based on the data source and it is the data source that determines what the fields are and their types. So whether you are getting doubles or decimals is up to the data source you are using and whatever you are using to retrieve the data.

The quick and simple answer would have been:

When using a SQL Float the UltraGrid will translate as System.Double, whereas any other SQL Floating type # will come across as System.Decimal.

This is what I mean by under the hood. Not that .Value is an object.

I have come to these forms because I expect you to be the expert in your product. Am I the lead developer? No. Do I make the decisions on what control sets to purchase? Yes. How do I base that decision? On the quality of support I receive.

This whole converstaion has left me truly annoyed and ready to just rip out Infragistics and go with DevExpress. And when we make the move to Silverlight, I should go with who based on this conversation...

melegant said:

what is more important is that I understand more what is going under under the hood with the grid

Not sure what you mean by "under the hood" here. The Value property on the cell is an object. That's not under the hood, it's pretty much right out in the open. :)

The cell has to be able to deal with any data type, so the Value has to a object type. It's the same with a DataSet/DataTable, UltraDataSource, the Microsoft grid, or pretty much any other object that deals with fields of data. The cell can't very well expose a property of every possible data type. I suppose the grid could expose cells of a Generic type, but the grid was written long before generics were available on DotNet, so that was not an option at the time.

melegant said:

Is there a way to specifiy that datatype of the column? I am using a datatable as the datasource for the grid.

There's a DataType property on the column. This gets set automatically based on the data structure of the data source the grid is bound to. But that doesn't change the fact that the Value property is (and has to be) an object. It's basically just for validation.

Ok, now we are getting somewhere.

So yes, I understand boxing but what is more important is that I understand more what is going under under the hood with the grid.

Basically if I have 2 columns from my database, one float and the other money (or decimal) then my cell values will be boxed up doubles and decimals respectivley. Since uboxing is an expensive process (as outlined in the article you sent over to me)  I am going to just have to choose a datatype and go with it. It is a loose loose situation since I gain performance on the .NET side by using double but also gain performance on the SQL side by having a fixed point decimal vs a float.

All of this is null and void because I of having to perform 2 operations to get what I want. At some point then the grid is boxing up the cells to a datatype. Is there a way to specifiy that datatype of the column? I am using a datatable as the datasource for the grid.  If I had that, then all issues are solved.