Hi,
We were on a really old version of Infragistics (11.2) and we recently upgraded to 16.1.
In the latest version, we found that we are getting an exception with the following code:
private void ut_Click(object sender, EventArgs e) { UltraTree utControl = (UltraTree)sender; if (utControl.ActiveCell == null) return;
switch (utControl.ActiveCell.Column.Key) { case "Checked": utControl.ActiveCell.AllowEdit = AllowCellEdit.Full; utControl.ActiveCell.BeginEdit(); if ((CheckState)utControl.ActiveCell.Value == CheckState.Unchecked || (CheckState)utControl.ActiveCell.Value == CheckState.Indeterminate) utControl.ActiveCell.Value = (int)CheckState.Checked; else if ((CheckState)utControl.ActiveCell.Value == CheckState.Checked) utControl.ActiveCell.Value = (int)CheckState.Unchecked;
utControl.ActiveCell.EndEdit(false); utControl.ActiveNode.Update();
Here's the stack trace:
See the end of this message for details on invoking just-in-time (JIT) debugging instead of this dialog box.
************** Exception Text **************System.NullReferenceException: Object reference not set to an instance of an object. at Infragistics.Win.UltraWinTree.UltraTreeNode.CommitCellValues() at Infragistics.Win.UltraWinTree.UltraTreeNode.Update() at OptiGlass.ctlOptimizer.ut_Click(Object sender, EventArgs e) at System.Windows.Forms.Control.OnClick(EventArgs e) at Infragistics.Win.UltraControlBase.OnClick(EventArgs e) at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks) at System.Windows.Forms.Control.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)
I did a
Not sure if we're doing something that was OK in 11.2 but is no longer OK in 16.1 or if this is a bug, but I wasn't able to find any information on this.
Thanks in advance!
Steve
Hi Steve,
I don't see anything inherently wrong with this code. It might be a bug. But I would need a sample project demonstrating the exception in order to know for sure.
I tried to create a sample, but I could not get it to work because there are too many unknowns here and a lot of this code just doesn't make a lot of sense to me.
You seem to be jumping through some pretty big hoops here in order to manually handle clicking on a cell that contains both CheckState and/or integer values. If you just want a Checkbox or CheckState column then there are MUCH easier ways to do that built-in to the tree and there's no reason to write code in the Click event to handle that.
What's the DataType of this column?
Why are you manually handling the Click event to toggle the value?
Also... the code you have will produce some very strange and unexpected results. You are not actually checking to see if the user is clicking on a cell. So if there is an ActiveCell in the tree and the user clicks on the tree's Background, a header, the scrollbar, or basically anything the doesn't change the ActiveCell to null, this code will end up toggling the ActiveCell even though the user clicked somewhere else.
Anyway, presumably this code has been working for you for a long time, so it may not be worth messing with it. If you can provide a sample that reproduce the exception, we will, of course, be happy to look into it. But if all you need is a checkbox cell in the tree, it might be better to just simplify the code and use the built-in functionality instead of jumping through hoops like you are doing here. That might get you up and running faster and avoid the exception.
Mike,
Again, I'm by means an expert on this, but I think what was trying to be accomplished in doing this in the click event:
- Change the image of the checkbox to a static image.
- Change the appearance of the other cells in the node to look disabled.
That's all I can think of at least.
If there's base functionality to accomplish this, can you link or provide a quick example? That would save me some digging.
Thanks for the quick response Mike, appreciate it.
To be wholly honest, I'm pretty unfamiliar with Infragistics and have no idea why this code was written as such, it is in fact legacy code, but I agree that seemed to be going in a roundabout way (and to be honest, our codebase is using this as a grid, not sure why the tree was used).
So unfortunately I don't have a good answer for any of this. I suppose I was hoping something obvious jumped out as a bug that would be fixed in latest so we didn't have to mess with re-thinking this or mocking up an example, but it sounds like that's the best solution for everybody.