I am having trouble with fieldlayouts in xamDataGrid where AutoGenerateFields is False.
Basically the grid is picking out a random field layout from my xaml for a nested relationship (hierarchy of related rows beneath a row).
I thought I could avoid the very undesirable behavior (random selection of a field layout) by using KeyMatchingEnforced="True" on all or one of the unmatching fieldlayouts. However, despite a clearly mismatching Key value on the random fieldlayout in question, the xamDatagrid is still picking it out for use.
Reading the KeyMatchingEnforced property documentation, there is a "Note:" for version 9.2. Am I correct in assuming that this note is a caveat that implies KeyMatchingEnforced no longer works properly? (ie. possibly for compatibility reasons or such)
Hello,
The XamDataGrid should only be selecting FieldLayouts where all of the Bound Fields have names equivalent to properties in the underlying object. If you have multiple field layouts that may match but want to ensure the correct one is selected then you should set the Key of that Field Layout to the name of the underlying object in the collection for that layout. If this is not working correctly for you can you please provide a simple sample illustrating the issue or provide more information on the type of data source you are using along with the objects in the collections and an example of the field layouts so I can look into your issue further.
Sincerely,
Valerie
Developer Support Supervisor - XAML
Infragistics
www.infragistics.com/support
Were you able to resolve your issue?
Sincerely,Valerie Developer Support Supervisor - XAMLInfragisticswww.infragistics.com/support
OK, I attached the repro.
Basically you need to make sure this compiles and executes. Try to look for a message ("Please find me now") which should *NOT* show up when you first run it.
The layout with Key "Random1" is preventing the desired layout from being shown (despite the fact that we use KeyMatchingEnforced=True attribute all over the place).
If you move that layout "Random1" to the bottom, the desired layout will finally be shown (ie "ContinuationConfirmation").
What is frustrating is the seemingly random logic that selects field layouts in the xamDataGrid. Ideally there should be a well-defined way of ensuring that an entity from the dataset is paired up to the correct fieldlayout. I 've found some workarounds by trial-and-error but the only pattern I've found so far is that KeyMatchingEnforced does makes absolutely *NO* difference in the field layout selection logic. It is just there as a tease.
In all seriousness, I'd like a well-defined way of making sure a table with a certain name (or FK relationship) is paired with the right field layout. If there are instructions for this I'd love to hear them (whether or not it involves KeyMatchingEnforced). Ideally the instructions should allow for fields that are 100% unbound (eg. using control templates and custom binding.)
For child field layouts, you should use the name of the Field in the parent field layout (foreign key) as the key to ensure that the correct field layout is used.
Please see modified sample.
Let me know if you have any questions.
I guess I can accept your answer but this convention is quite confusing and a bit obscure. It is confusing because the fieldlayout keys you used do not align with the keys that are generated automatically (*see PS below). Based on samples and blogs I've seen in the past, it was common to use the automatically generated fieldlayouts as a starting point (ie. after saving the related xaml representation.)
But you are telling me that the automatically generated fieldlayouts have bad keys and/or are incompatible with KeyMatchingEnforced logic. At least that's what I'm hearing.
Thanks,
David
*PS. Generating fieldlayouts automatically is fairly easy. If you remove all the fieldlayouts after the one for runs (now named FK_Batch_Run), you will see that they get keys assigned automatically (see output from FieldLayoutInitialized event).
Thank you for your feedback, while using the foreign key will ensure the correct layout I do see your point about using the table name. Therefore, I have asked our engineering staff to examine this further. To ensure that it will receive attention, I have logged this behavior in our internal tracking system with a Development ID of 184834. The next step will be for a developer to review my investigation and confirm my findings or to offer a fix, or other resolution.
I have also created a private case, CAS-145971-W9J5G7, to track this issue for you.
Thank you for this diligence.
Even if using the "right" key format - based on FK name - fixed the problem, it never really explained why the *wrong* fieldlayout key ("Random1" or whatever) should have ever been used in the first place (see my original example).
That additional complaint had come to mind once I started using your suggested work-around. But I didn't want to be too picky since I'm moving forward again...