Hello, I'm new to the Infragistics product line and am attempting a large conversion project from an old version of Infragistics. While doing this I'm trying to get up to speed on the various controls in version 16 and was wondering if someone could explain to me why e.RowId is stored as an object of type 'Infragistsics.Web.UI.GridControls.IDPair. Because of this I'm forced to dig into the object to grab the ID that I'm looking for.
All examples I'm finding online show something along the lines of id=CInt(e.RowID.Key(0)) which just makes me uncomfortable because I'm explicitly calling an index in an array so I have make sure it's there first. Why isn't it simple id = e.RowID?
The only reason I can think of is in the case of objects with multiple identifiers such as compound keys in a database table so maybe that's why. I'm not complaining, I'm just trying to get a better understanding. Thanks for the help.
EDIT: I neglected to mention that I'm looking at e.RowId in the context of a WebDataGridt.RowUpdating event.
Hi User42,
Thank you for posting in our forums!
I am not sure, personally, why this is the chosen method to identify the rows. With some simple testing, you may be right about compound keys. When you have a compound key, they are all stored in the IDPair.Key.
I have contacted the grid's development team so they may shed some more light on this.
Someone from the dev team for the grid had the following to say about this:
The IDPair contains not only the index of the row in the set of rows, but also the row DataKey, which is the unique identifier.
The RowUpdating event also provides the specific row's class object and you could also use these properties if it's more suitable: - e.Row.DataKey(0) - to get the unique identifier - e.Row.Index - to get the row index
The concern of always checking for a valid index seems excessive. If there is no row in the EventArgs or the RowId has no key, then this should be a bug. Nevertheless they can always use the ContainsKey method to make sure the key is there.
If you have any further questions or concerns with this, please let me know and I will be glad to help.
Hi Michael, thanks for the update and explanation. I will take this information and use it accordingly.
I can understand that the check for a valid index seems excessive I just have a habit of always checking for valid values when explicitly calling out an index in an array. I'll have to overcome that quirk in this case :)