We use data in XamDataGrid where the columns are only known at runtime, and so bind to an ObservableCollection<BindableDynamicDictionary> as found on:
https://stackoverflow.com/questions/14171098/binding-datagrid-to-observablecollectiondictionary
The fields are created by handling the FieldLayoutInitialized event.
In general, it works pretty well. Sometimes, the data in the VM gets changed (new/removed/relabeled columns, etc.) and we need the grid to update. To do that we are handling DataSourceChanged and in v16.x and before it would work if we called 'grid.DefaultFieldLayout.Fields.Clear()'. Then FieldLayoutInitialized would fire and the new columns would be set.
Now with v17.x (we're currently on v17.2), the DefaultFieldLayout.Fields.Clear() does remove the existing columns, but FieldLayoutInitialized is not called again and the grid contains no columns.
I'd like to fix this problem, but I'm also open to alternative solutions.
Hello Walter,
Thank you for the detailed steps for reproducing the issue you have provided.
I tested the behavior you have described in regards to clearing the Fields collection of the DefaultFieldLayout and having the FieldLayoutInitialized event fired and I was not able to reproduce it in the last Service Release for WPF 16.2 (16.2.20162.2237).
Would you please provide me with more detailed information on the specific product and build version (as I have above) you have used when the behavior of the FieldLayoutInitialized event getting fired after clearing the Fields collection was present?
It would also be great if you could provide me with a sample application, where the above behavior is reproduced. Having this information will help me further investigate this matter for you.
If you have any questions, please let me know.
Right now I'm working with v17.2. Here is an app, and while it isn't exactly as I described it in the other app (which I cannot explain), it shows some oddities.
Thank you for the sample application you have provided.
I have investigated your issue in regards to the FieldLayoutInitialized event not getting fired after clearing the Fields collection of a FieldLayout in the DataSourceChanged event and I have asked our engineering staff to examine this further. I have logged this behavior in our internal tracking system with a Development ID of 246255. This will be assigned to a developer in a future sprint to review my investigation and confirm my findings or to offer a fix, or other resolution.
Please let me know if you need more information.
It appears that the behavior has been largely fixed in v17.2.20172.2029; I am still seeing curious behavior in this app where if I add a row by typing data in the grid, and then switch to another tab, the grids seem to disappear for a few tabs before coming back.
ScratchApp.zip
I have been testing the new sample project that you have provided against version 17.2.20172.2029, and I am seeing some adverse behavior with it, although these behaviors appear to be timing issues between the TabControlResetGridBehavior and the InitializeBindableDynamicDictionaryFieldBehavior behaviors that you are applying.
On my end, if I switch the selected tab in the XamTabControl, I see the XamDataGrid always, but there are no Fields shown. This appears to be a timing issue between the FieldLayout.Fields.Clear() call in the SelectionChanged event as if I remove the XamTabControl's behavior, the Fields are populated and rendered normally.
Alternatively, if I place the code that exists in the FieldLayoutInitialized event inside of a Dispatcher.BeginInvoke Action, I am also able to see the Fields rendered correctly, further increasing my suspicion that this is a timing issue between the behaviors that you have applied.
The behavior that I am seeing seems to be a little bit different from the new behavior that you are reporting, but the only way I can actually switch tabs with your sample and have the XamDataGrids have their Fields appear is if I either remove the XamTabControl behavior or add the Displatcher.BeginInvoke action. As such, I am wondering if the timing issue I am seeing is somehow related to the issues you are seeing. As a test, would it be possible for you to try removal of the XamTabControl behavior or placing the FieldLayoutInitialized event code in a Dispatcher.BeginInvoke Action to see if the behavior still happens? This would allow us to truly see if it is a timing issue between the two behaviors you have provided. For reference, the Dispatcher Action code would look like the following:
Dispatcher.BeginInvoke(new Action(() => { //Field Layout Initialized Code Here! }));
Please let me know if you have any other questions or concerns on this matter.
Sincerely,AndrewAssociate Developer