Hello!
I use the TreeListInplaceEditViewController from E443. I just upgraded the application from 17.1.4 to 19.1.4 and now suddenly get errors in that controller.
The problem is that treeList_CellValueChanged gets called when the TreeList is initialized (in an XAF-ListView) and the event data that is sent to event handler (from TreeList) seems faulty. In my crash case the event data e.Column is a "Name"-column but the e.Value is a bitmap. This finally leads to an conversion error in the event handler (in the call of focusedColumnMemberInfo.SetValue( …)).
When I debugged into TreeList.OnSetValue method (which finally triggers CellValueChanged event) I found out that the columnID parameter there was (so far correctly) of an Icon column in my business object and therefore the val parameter was correspondingly a bitmap. But the obvious problem in this method then seems to be the following event triggering call:
C#RaiseCellValueChanged(new CellValueChangedEventArgs(FocusedColumn, node, val));
So the reason why I get faulty event values is that here "FocusedColumn" gets passed (which in that case is not the "Icon"-column but the "Name"-column).
Isn't this a bug?
Furthermore do you have a good idea how I could prevent that all the code in treeList_CellValueChanged is executed when the TreeList is initialized or refreshed. The code in that handler only makes sense when a user manually edited a TreeList cell? My solution and workaround to all of this so far is that I set a flag in treeList_ShownEditor and the treeList_CellValueChanged code is only executed when that flag was set before. Maybe this is good enough.
Regards,
Johannes
It seems to be more of an problem that TreeList.CellValueChanged is fired at all on opening/refreshing a list view. At least according to docu it should: "Fires immediately after a user closes a cell editor with a modified value."
So maybe the stacktrace might be helpful as well:
MyApp.Module.Win.dll!MyApp.Module.Win.Controllers.TreeListEnableInplaceEdit.TreeListInplaceEditViewController.treeList_CellValueChanged(object sender, DevExpress.XtraTreeList.CellValueChangedEventArgs e) Line 123 C#
DevExpress.XtraTreeList.v19.1.dll!DevExpress.XtraTreeList.TreeList.RaiseCellValueChanged(DevExpress.XtraTreeList.CellValueChangedEventArgs e) Unknown
DevExpress.XtraTreeList.v19.1.dll!DevExpress.XtraTreeList.TreeList.OnSetValue(DevExpress.XtraTreeList.Nodes.TreeListNode node, object columnID, object val) Unknown
DevExpress.XtraTreeList.v19.1.dll!DevExpress.XtraTreeList.Nodes.TreeListNode.SetValue(object columnID, object val) Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.SetNodeValue(DevExpress.ExpressApp.Win.Controls.ObjectTreeListNode controlNode, DevExpress.XtraTreeList.Columns.TreeListColumn column) Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.OnControlNodeBuild(DevExpress.ExpressApp.Win.Controls.ObjectTreeListNode controlNode) Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.BuildControlNode(object nodeObject, DevExpress.ExpressApp.Win.Controls.ObjectTreeListNode parentNode) Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.LoadFromDataSource() Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.UpdateDataSource(bool updateContent) Unknown
DevExpress.XtraTreeList.v19.1.dll!DevExpress.XtraTreeList.TreeList.UpdateDataSourceOnChangeDataSource() Unknown
DevExpress.XtraTreeList.v19.1.dll!DevExpress.XtraTreeList.TreeList.DataSource.set(object value) Unknown
DevExpress.ExpressApp.Win.v19.1.dll!DevExpress.ExpressApp.Win.Controls.ObjectTreeList.DataSource.set(object value) Unknown
DevExpress.ExpressApp.TreeListEditors.Win.v19.1.dll!DevExpress.ExpressApp.TreeListEditors.Win.TreeListEditor.UpdateControlDataSource() Unknown
DevExpress.ExpressApp.TreeListEditors.Win.v19.1.dll!DevExpress.ExpressApp.TreeListEditors.Win.TreeListEditor.treeList_HandleCreated(object sender, System.EventArgs e)
Hello, Johannes.
I tried to reproduce the issue regarding mismatching columns in the CellValueChanged event handler using the E443 example converted to version 19.1, but to no avail. Would you please provide detailed instructions on how to reproduce it in this example? If this occurs only in your own project, modify the example to replicate your scenario.
Hello Michael,
thank you for checking.
With the tickets that Martin linked, it seems that E443 should just be updated to use CellValueChangedEventArgs.ChangedByUser in future versions.
I think there is no need to do some special reproducing anymore as the bug is pinpointed in TreeList.OnSetValue with passing the FocusedColumn at the RaiseCellValueChanged call. As I read in the linked tickets DX seem to think that it's a good idea that the event is raised also when the change isn't done by the user. Therefore you can't pass FocusedColumn anymore there (that was ok before when the event was raised only by user changes - so it was safe to assume that FocusedColumn was the column that was changed). Maybe that is already fixed for 19.2.5 with the fixes/changes for the linked tickets.
Just as an aside: Maybe I wouldn't have stumbled accross this problem on opening the list view if I wouldn't restore the TreeList state from the model (some custom implementation). Because then FocusedObject might still have been null at the time that treeList_CellValueChanged from E443 is called and I wouldn't have got the conversion error because of null check of focusedObject there. Would have got the error f.e.on reverting pending changes in the list view though.
Regards,
Johannes
Further note: The problem was obviously introtuced in 19.1.4 (in case you tried with another version)
See here Johannes - the problem with the focusedcolumn should also be fixed i think:
https://www.devexpress.com/Support/Center/Question/Details/T752283/treelist-cellvaluechangedeventargs-is-always-focusedcolumn-in-the-cellvaluechanged-event
all in all that change in an minor release was really heavy…
Thanks, Martin. Seems that I am just ruminating a bunch of tickets ;-)
When I think that I upgraded the application from 17.2.5 and the nearly only and most breaking change was introtuced in a minor version then I fully agree with the "heavy" label.
Thank you for your feedback. Please inform us of your results once you have had the opportunity to test your project with the hotfix or the next maintenance update.