Hi Infragistics,
I'm trying to investigate an infinite loop issue which seems to be happening inside Infragistics XamDataGrid. We have a functionality in our app that let's the user to save and load various customisations he made in his XamDataGrid including FieldLayouts. I can't really tell you what exactly has happened under the cover, but XamDataGrid ended up persisting an inconsistent state of FieldLayouts which looks like this in XML format. Using SaveCustomizastions() method.
<GridLayout name="andor1" type="User"> <Option> <xamDataPresenter version="10.1.20101.2018" formatVersion="1.5"> <fieldLayouts> <fieldLayout key="" fieldList="RowStatus;ResultDataRowStatus, [...]"> <sortedFields> <sortedField direction="Ascending" fieldName="DealStartDate" isGroupBy="false" /> </sortedFields>
<fields> <field name="RowStatus" FixedLocation="FixedToNearEdge" Visibility="Visible" IgnoreFieldVisibilityOverrides="false" row="0" column="36" rowSpan="1" columnSpan="1" isCollapsedInLayout="false" />[...] </fields> </fieldLayout> <fieldLayout key="" fieldList=""> <parentFieldLayout key="" fieldList="RowStatus;ResultDataRowStatus, [...]" /> </fieldLayout> </fieldLayouts>
What I really don't like in this is that the 2nd layout refers to a parentLayout which has the same <empty> key and using the same key for different layout really smells like an infitine loop root cause here.
Loading the above XML works fine with LoadCustomisations() method, but various other functionality stops working. For example setting the EditorStyle of a field in code causes the application to hang forever.
Here's the call stack I got from debugger for that call:
Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.GroupByAreaMulti.SynchronizeFieldLayouts(bool calledFromApplyTemplate) + 0x218 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.GroupByAreaMulti.OnStyleVersionNumberChanged() + 0x7 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.GroupByAreaBase.OnStyleVersionNumberPropertyChanged(System.Windows.DependencyObject target, System.Windows.DependencyPropertyChangedEventArgs e) + 0x20 bytes WindowsBase.dll!System.Windows.DependencyObject.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs e) + 0x4a bytes PresentationFramework.dll!System.Windows.FrameworkElement.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs e) + 0x50 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.GroupByAreaBase.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs e) + 0x27 bytes WindowsBase.dll!System.Windows.DependencyObject.NotifyPropertyChange(System.Windows.DependencyPropertyChangedEventArgs args) + 0x2c bytes WindowsBase.dll!System.Windows.DependencyObject.UpdateEffectiveValue(System.Windows.EntryIndex entryIndex, System.Windows.DependencyProperty dp, System.Windows.PropertyMetadata metadata, System.Windows.EffectiveValueEntry oldEntry, ref System.Windows.EffectiveValueEntry newEntry, bool coerceWithDeferredReference, System.Windows.OperationType operationType) + 0x515 bytes WindowsBase.dll!System.Windows.DependencyObject.SetValueCommon(System.Windows.DependencyProperty dp, object value, System.Windows.PropertyMetadata metadata, bool coerceWithDeferredReference, System.Windows.OperationType operationType, bool isInternal) + 0x1eb bytes WindowsBase.dll!System.Windows.DependencyObject.SetValue(System.Windows.DependencyProperty dp, object value) + 0x2e bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.GroupByAreaBase.StyleVersionNumber.set(int value) + 0x24 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.DataPresenterBase.BumpGroupByAreaStyleVersion() + 0x24 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.Field.ProcessFieldSettingsPropertyChanged(System.ComponentModel.PropertyChangedEventArgs e, Infragistics.Windows.DataPresenter.FieldSettings settings, object settingsOwner, bool firstPassForPresenterFlag, bool firstPassForFieldLayoutFlag, Infragistics.Windows.DataPresenter.Field field, Infragistics.Windows.DataPresenter.FieldLayout fieldLayout, Infragistics.Windows.DataPresenter.DataPresenterBase presenter) + 0xc61 bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.Field.OnSettingsPropertyChanged(object sender, System.ComponentModel.PropertyChangedEventArgs e) + 0x55 bytes Infragistics3.Wpf.v10.1.dll!Infragistics.Windows.Helpers.DependencyObjectNotifier.RaisePropertyChangedEvent(string propertyName) + 0x3a bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.FieldSettings.OnPropertyChanged(System.Windows.DependencyPropertyChangedEventArgs e) + 0x31 bytes WindowsBase.dll!System.Windows.DependencyObject.NotifyPropertyChange(System.Windows.DependencyPropertyChangedEventArgs args) + 0x2c bytes WindowsBase.dll!System.Windows.DependencyObject.UpdateEffectiveValue(System.Windows.EntryIndex entryIndex, System.Windows.DependencyProperty dp, System.Windows.PropertyMetadata metadata, System.Windows.EffectiveValueEntry oldEntry, ref System.Windows.EffectiveValueEntry newEntry, bool coerceWithDeferredReference, System.Windows.OperationType operationType) + 0x515 bytes WindowsBase.dll!System.Windows.DependencyObject.SetValueCommon(System.Windows.DependencyProperty dp, object value, System.Windows.PropertyMetadata metadata, bool coerceWithDeferredReference, System.Windows.OperationType operationType, bool isInternal) + 0x1eb bytes WindowsBase.dll!System.Windows.DependencyObject.SetValue(System.Windows.DependencyProperty dp, object value) + 0x2e bytes Infragistics3.Wpf.DataPresenter.v10.1.dll!Infragistics.Windows.DataPresenter.FieldSettings.EditorStyle.set(System.Windows.Style value) + 0xc bytes > >>> Our code <<<The only workaround I've found so far is keeping only the first layout before persisting the state of the grid.
Regards,
Andor Molnar
HI,
Can you atttach small isolated sample that reproduces this issue?
Sincerely, Matt Developer Support Engineer.
I
Hi Matt,
I will give it a try, but not really sure I'm able to reproduce the problem in a sandbox. There're a lot of stuff (event handlers, bg processing, etc.) happening under the cover and to be honest I haven't managed to get to the bottom of it. To put it in a nutshell, I have no idea how and where that extra FieldLayout gets generated.
After all, shouldn't XamDataGrid protect itself against such scenarios, at least at the time where the invalid layout is being added?
Andor