Hi guys,
we have a messaging service that broadcasts a couple of messages every 1-5 seconds.
When our client module receives those messages, we want to append them at the bottom of a grid (RadGridView).
After appending them, we also want to scroll to the very bottom of that grid, so that the newest and therefore bottommost items come into view.
Documentation and forums suggest we go the AttachedBahaviour and ScrollIntoViewAsync way.
Our behaviour looks like this:
public class ScrollToNewItemBehavior : Behavior<RadGridView>
{
public static bool GetIsEnabled(DependencyObject obj) => (bool)obj.GetValue(IsEnabledProperty);
public static void SetIsEnabled(DependencyObject obj, bool value) => obj.SetValue(IsEnabledProperty, value);
public static readonly DependencyProperty IsEnabledProperty = DependencyProperty.RegisterAttached("IsEnabled", typeof(bool), typeof(ScrollToNewItemBehavior), new PropertyMetadata(false, OnIsEnabledChanged));
private static void OnIsEnabledChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
if (d is RadGridView gridView)
gridView.Items.CollectionChanged += (s, args) =>
{
if (args.Action == NotifyCollectionChangedAction.Add)
{
gridView.ScrollIntoViewAsync(args.NewItems[0], gridView.Columns[0], null);
// exchanging args.NewItems[0] for gridView.Items[gridView.Items.Count-1] yields same result
//gridView.ScrollIntoViewAsync(gridView.Items[gridView.Items.Count-1], gridView.Columns[0], null);
}
};
}
}
Our Message class:
public class Message : ModelBase<Message>
{
public string Text { get; set; }
}
Our Messages collection in the ViewModel:
private RadObservableCollection<Message> _messages;
public RadObservableCollection<Message> Messages
{
get => _messages;
set
{
_messages = value;
NotifyPropertyChanged(m => m.Messages);
}
}The collection is updated (in the ViewModel) like this:
Task.Run(async () =>
{
for (int i = 0; ; i++)
{
await Task.Delay(1000);
Messages.Add(new Message { Text = $"{i} - sftrvwj,erhvtwejhrfvtjlwehftrwejh" });
}
});
The grid is defined like this:
<telerik:RadGridView
x:Name="gridView"
ItemsSource="{Binding Messages, Mode=OneWay}"
IsSynchronizedWithCurrentItem="False"
IsPropertyChangedAggregationEnabled="True"
AutoGenerateColumns="False"
SelectionMode="Single"
CanUserFreezeColumns="False"
EnableColumnVirtualization="True"
EnableRowVirtualization="True"
CanUserDeleteRows="False"
CanUserInsertRows="False"
behaviours:ScrollToNewItemBehavior.IsEnabled="True"
CanUserGroupColumns="False"
IsReadOnly="True"
IsManipulationEnabled="False"
CanUserReorderColumns="False"
CanUserSearch="False"
ShowGroupPanel="False">
<telerik:RadGridView.Columns>
<telerik:GridViewDataColumn
DataMemberBinding="{Binding Text}"
Header="Text"
ShowDistinctFilters="False"
IsSortable="False"/>
</telerik:RadGridView.Columns>
</telerik:RadGridView>
Nothing too fancy.
What we observe:
When a message is added, the view and the scroll indicator randomly jump to the top or the bottom of the grid and stay there until the next message is added.
We tried AddRange, Suspend-/ResumeNotifications, ObservableCollection instead of RadObservableCollection.
We disabled many grid features.
We tried .NetCore
we tried .net Framework
To no avail.
This seems to be a bug.
Do you know any workarounds or a completely different approach to achieve the desired behaviour?
Side note:
When we set GroupRenderingMode to Flat,
GroupRenderMode="Flat"
the view stays at the bottom. The scroll indicator stays at the bottom as well, but once in a while jumps a little bit up, as if by one row, and down to the bottom again without the view changing.
At one time disabling filtering on all columns seemd to work... but later didn't.
Thanks in advance
Thorsten
When you have rows grouped by null value and you try to move one of the rows to another group, a NullReferenceException is thrown.
This is reproducible only when DataView is used as ItemsSource of RadGridView.
To work this around, avoid using null values. Or avoid using DataView.
The GroupRenderMode of the RadGridVIew is set to Flat. The control is populated with items that implement the IList interface. The Count property of the custom objects needs to return value bigger than 1. So when the Delete button is pressed, the rows beneath the deleted one will also be deleted. Their number depends on the Count property of the custom object.
To reproduce this:
- Set the GroupRenderMode of RadGridView to Flat.
- Page RadGridView using RadDataPager.
- Scroll to the last row in the view. Or scroll to any row so that few of the rows above are not longer visible.
- Expand the row details and scroll down more until only the parent row is visible.
- Collapse the row details. At this point, the vertical scrollbar disappears and the upper rows are not brought into the view as expected when the row details gets collapsed.
To work this around call the Rebind() method of RadGridView on RowDetailsVisibilityChanged event.
private void RadGridView_RowDetailsVisibilityChanged(object sender, Telerik.Windows.Controls.GridView.GridViewRowDetailsEventArgs e)
{
if (e.Visibility == Visibility.Collapsed)
{
this.gridView.Rebind();
}
}
The issue appears also without UI virtualization and in the Nested mode. It happens on ItemsSource reset of RadGridView, in case the old ItemsSource value wasn't empty. The DataContext is set to null for a brief moment before the old visuals are removed from the view, which causes issues in some scenarios related to CellTemplate
Since i cannot upload zip-files in the Forum I am doing it here.
The problem is, that a single grouping dramatically increases the time for sorting the values.
When the grouping is not present, sorting the same column is much faster.
It appears that it is related to the ammount of columns in total (not grouped).
The ammount of records is not so important, 100 (as in the attached sample) should not be significant.
Blank spaces where rows should appear are observed in the following situation. You start editing a row or a column, then scroll the row outside of the viewport before the edit was committed. Then sort a column.
This is reproducible only if the GroupRenderMode property of RadGridView is set to Flat. Also, the AutoGenerateColumns property should be set to False and the Columns should be added manually.
Note that the issue is reproducible also in RadTreeListView, which has the GroupRenderMode set to Flat by default.
To work this around, set the GroupRenderMode property of RadGridView to Nested.
SearchStateManager property is null when trying to change any of the properties of the SearchStateManager object in the Loaded event. This behavior is observed when the ShowSearchPanel property is not set to true initially.
When pressing F10, the received key is Key.System.
We noticed that RadGridView does not get garbagecollected sometimes.
So i fired up a memory analyzer to see what is going on.
This is the graph that shows that the RadGridView is causing a leak. The only references that keep the GridView from getting collected are those two WeakEventListeners
To further investigate i decompiled GridViewDataControl and could identify the culprit.
private void SubscribeToDispatcherShutdown()
{
if (this.dispatcherShutdownListener != null)
this.dispatcherShutdownListener.Detach();
this.dispatcherShutdownListener = new WeakEventListener<GridViewDataControl, object, EventArgs>(this);
this.dispatcherShutdownListener.OnEventAction = (Action<GridViewDataControl, object, EventArgs>) ((grid, source, eventArgs) => grid.OnDispatcherShutdownFinished(source, eventArgs));
this.dispatcherShutdownListener.OnDetachAction = (Action<WeakEventListener<GridViewDataControl, object, EventArgs>>) (weakEventListener => this.Dispatcher.ShutdownFinished -= new EventHandler(this.dispatcherShutdownListener.OnEvent));
this.Dispatcher.ShutdownFinished += new EventHandler(this.dispatcherShutdownListener.OnEvent);
}
In the second line from the botton
... weakEventListener => this.Dispatcher.ShutdownFinished -Which kind of defeats the prupose of having a WeakReference inside your WeakEventListener.
Sadly i cannot figure out how it happens, but i think its only when Detach (FrameworkElement.Unloaded ultimately) is not called.
While this is the actual issue, i thought I'd share this with you so you.