Hi,
Is there any way to change the field position by code in the field layout?.
The ActualPosition property is read only and changing the Column property has not effect... I guess that the ActualPosition property as priority over the Column property.
Anyone?
Thanks.
Hello sebl,
The FieldCollection object inherits an ObservableCollection<Field>. You can utilize the ObservableCollection's Move() method to accomplish what you are looking for. For example:
grid.FieldLayouts[0].Fields.Move(1, 0);
The two integer parameters are the oldIndex and newIndex, respectively.
For more information, you can see the documentation here.
OK,
This does allow me to change the index of the field, but the property ActualPosition is still the one that seems to be used when displaying the fields.
In the end, all fields remain at their current position.
Actually, I can reproduce this without calling the LoadCustomizations method. I believe this could be a possible issue. I am going to investigate this and follow-up here.
Regards,
Alex.
OK, Thanks. I hope there is some kind of workaround.
What I was saying is that you can reproduce the problem by either changing a column's position by Drag&Drop OR calling LoadCustomizations.
I will create a support case on your behalf and link it to this issue. There is a way around this. The Column, Row properties are not take into consideration if the user has moved,fixed, loaded customizations. That is why you have to call the ClearCustomizations() method. Here is one option that you have:
xamDataGrid1.ClearCustomizations(
CustomizationType.FieldPosition);
FieldCollection fields = xamDataGrid1.FieldLayouts[0].Fields;
fields.Move(0, 3);
Regards,Alex.
Calling ClearCustomizations would reset the position of all columns. I only want to move 1 column to the hand of the label presenter.
Any update on this?
I have a similar scenario. When the column is unpinned, it has to move to the previous position not the first position. I am trying to circumvent that problem using Move method, still i am struck because of this weird behavior when moved/fixed/loaded customizations.
Hello,
Actually this is not the same scenario. Tthe QA Team confirmed that this the expected behavior of the Fixed Fields feature. If you would like this as an option for the fields to go back to their original position, you can submit a feature request on this link.