I have a ado.net dataset which I am binding to the xamDataGrid.
My XamDataGrid.FieldLayoutSettings has AutoGenerateFields="False".
I am able to manually define my hierarchical child field layouts correctly for relations that I care about.
But I am also seeing some other odd fieldlayouts being created that I don't want/need. I can see them during fieldlayoutinitialized events. They stem from a method FieldLayoutCollection.InitializeChildFieldLayouts which seems to be iterating over table relationships. Where regular relationships are concerned I don't get unwanted fieldlayouts.
However, the TypedListPropertyDescriptorProvider seems to be picking up on byte[] columns and creating child field layouts for them. I'd rather this not happen since the screen is already getting slow. Why are they being created when I specified AutoGenerateFields="False"? I'm looking into work-arounds and would be open to suggestions.
Hi,
Thank you for your post. I have been looking into your issue and on my side when defining the field layouts of the XamDataGrid manually(AutoGenerateFields="False"), no additional fields are shown on ‘FieldLayoutInitialized’ event of the XamDataGrid. Only these fields defined by me are available. I am attaching a sample application(DataGridHierarchyFields.zip). Please see the results in the Output window when the field layouts are initialized.
Let me know if this issue occurs with my sample application on your machine.
Thank you for the prompt reply. I really appreciate this effort.
One minor change should be to use ADO.Net and add the byte[]. See attached.
One thing you may want to do is look at a special property on FieldLayoutInitializedEventArgs ....
In the debugger watch window it is _propertyDescriptorProviders . I think it helps figure out what the ITypedList (or whatever for DataView) property descriptor is that initiates the creation of the layout. Took me forever to find this....
Hi Inacio,
Thank you for your reply. I have been looking into your question and my suggestion is to define your field layout in code behind. For more information please look into the following link:
http://help.infragistics.com/Doc/WPF/2014.1/?page=xamDataPresenter_Define_a_Field_Layout.html
Could you please explain me in details what exactly is the issue and how it breaks your application?
It would be great, if you attach some descriptive screenshots.
Looking forward to hearing from you.
We have shipped out a new service release where your issue is resolved. I'd be glad to find out if you had tested it out and if it had met your requirements.
You can download the Service Releases by logging to our web site and going to Account\My Keys and Downloads.
Hello,
I have logged this behavior with our developers in our tracking system, with an issue ID of 182034. I have also created a support ticket on your behalf with number CAS-144096-P5J7F6 in order to link the development issue to it so that you are automatically updated when a Service Release containing your fix is available for download.
I contacted our development team about more information on this matter.
I will update your shortly.
Thank you for understanding.
Performance of our WPF data entry apps is becoming a significant challenge. Getting to the bottom of this case will be a good starting point.
I've reported the case to Infragistics support (CAS-144513-Y9F4W2 ). Just want to keep you in the loop.
The reason for my posting was to find out *why* the xamDataGrid is building a number of additional fieldlayouts even though it was not the intention. Please see the sample attachment.
The problem does not cause the application to "break" so-to-speak, but creates a performance problem, given the number of byte[] columns. These should not be triggering the creation of new fieldlayouts (hidden or otherwise). This is my understanding.
I am not happy with the idea of abandoning XAML for code-behind (when it comes to declaring field layout definitions). In any case, if I can't prevent the additional fieldlayouts from being created in a xaml-based solution, I probably can't prevent this in code-behind either.
Is this issue something I should open a support case for? Did you look at my attached repro?