Hello there, in our project we need to add FieldGroups into the FieldItems list of the FieldLayout. We need to do this from VM, since our view component is a generic one, meant to be reused. Our problem is that adding the FieldGroups into the FieldItems links to unexpected behavior, like columns with bad arrangement, index out of range exception.The code from below is from a bigger method, but this part is responsible for adding FieldGroups to FieldItems collection. (It works, but not as good as we hoped.)
if (!string.IsNullOrEmpty(column.Group?.Id)) { if (!groups.TryGetValue(column.Group.Id, out var group)) { group = new FieldGroup { Label = column.Group.Label, AllowHiding = column.Group.AllowUserHiding ? AllowFieldHiding.ViaFieldChooserOnly : AllowFieldHiding.Never, Visibility = column.Group.Visibility, LabelTextAlignment = column.Group.LabelAlignment }; groups[column.Group.Id] = group; } group.Children.Add(field); } else fieldLayout.FieldItems.Add(field); } foreach (var group in groups.Values) if (!fieldLayout.FieldItems.Contains(group)) fieldLayout.FieldItems.Add(group);
Hi Alexandru,
Thank you for the detailed description.
I tested a similar setup in the previously shared sample in addition to saving and loading the grid state in both version 22 and latest (25.2). Although I am not sure I currently reproduce the described even in version 22.
The previously mentioned issue with ID 36912 could be the clue indeed. However, the custom programmatic field layout definition could still be related, which would explain why I am not currently able to reproduce in the sample. I am also testing with a smaller number of columns.
The best approach would be for you to verify whether the mentioned fix addresses the particular scenario in your app as well.
A valid license would be required to update versions. With an active subscription, you do have access to any version. In case you do not currently have an active subscription, you could test your app or a fork of it against the trial NuGet package, which is always against the latest release and is available publicly. If you need assistance to set this up, please, let me know.
I case the unexpected behavior is still observed in the latest version, I would ask you to please, isolate it by modifying the previously shared sample with the specific programmatic field initialization logic as well as the needed number of columns to reproduce it. No need to add any save/load customizations logic.
This will be very helpful in order to identify whether the reported is either related to the already fixed issue, caused by the custom application code, or is a separate issue for the XamDataGrid. Thank you for your cooperation.
Best regards,
Bozhidara Pachilova
Hello,I'll describe exactly our problem:In our grid we have 5 "ungrouped" columns and 4 groups:- At moment 0 these 5 "ungrouped" columns are the first 5 elements in the grid, followed by the groups.- At moment 1 the user drag and drops one of the "ungrouped" columns (let's call this column, column X)between the groups (not inside one of them, but in between the groups). Now the ActualPosition prop of the column Xholds the value (0,11,1,1) (11 stands for the column index).- At moment 2 the user closes the UI and grid.SaveCustomizations (from Infragistics) is called.- At moment 3 the user opens again the UI and grid.LoadCustomizations is called (method from Infragistics again).At moment 3 the column X.ActualPosition is still (0,11,1,1), but visually in the grid it stands at position 9.We learned that this is caused by "ungrouped" collapsed columns(in the described case we had 2 collapsed columns),since they dont occupy space visually but they do in the behind holded tree.We have a custom behavior implemented by us where these columns have to stay collapsed sometimes and dont break the drag and drop behavior.
Any idea on this?
Another question, we currently use a 22 infragistics version( we know its old),do we have to buy a new license for a newer version? Or the old license will provide us the newer infragistics version?
Thanks a lot your assistance!
After further investigation, I determined that there has recently been addressed an issue in the library about initially collapsed fields or field groups being displayed as last in the field chooser layout and when their visibility is toggled. I believe this corresponds to your description.
As I am not able to reproduce this in the sample when setting some of the field groups as Collapsed initially, I believe this is really the same issue. Hence I am wondering what version of Ultimate UI for WPF your app targets?
This is listed in the Bug Fixes under the October 2025 release here, with ID 36912.
To take advantage of the fix, please, upgrade your project to the latest releases of versions 24.2.x, 25.1.x, or 25.2.x, depending on which version your app uses.
If you need any further assistance, please, let me know.
Hello, so here is the order of the fields and fieldGroups in the grid:but when we make the 'Seismic Load' group visible from Field Chooser, it is not displayed at the 14 position.(by default the 'Seismic Load' is hidden). I suppose the fields should appear in the grid as they are in the above image(that s what we need, to have the same order).I hope this makes our objective easier to understand.
Please, find attached a modified version of the sample, where the position of the programmatically created fields and groups is controlled by using the Insert method on the FieldItemsCollection instead of Add.
Regarding the field chooser, by default fields would be ordered alphabetically in the field chooser, despite their order in the field layout definition. It is possible to change the value of the FieldDisplayOrder property of the FieldChooser. This can be done in the FieldChooserOpening event handler. More details can be found here. The FieldChooserDisplayOrder.SameAsDataPresenter value is probably what you are looking for. The sample also shows this.
Finally, I am not convinced if the _templateCellIndex property is representative of the visible column index in that case. There’s also the “IndexInParentGroup” property, which might be more applicable for debugging purposes, or the Field ActualPosition. Consequently, I am not sure what you mean by “when we reset the user settings”, so, please provide further clarifications, if the sample does not accurately demonstrate what you’re trying to achieve.
Best regards,Bozhidara PachilovaSoftware Developer
5810.XDGDynamicFieldLayout (2).zip