After upgrading from Telerik UI for .NET MAUI 13.0.0 → 13.2.0, a NullReferenceException is thrown inside SchedulerAgendaView.Init() on Windows (WinUI3) whenever a RadScheduler with an AgendaViewDefinition is used. The scheduler never renders and the app receives an unhandled exception.

Steps to Reproduce:

1. Create a .NET MAUI app targeting Windows (WinUI3)
2. Add a ContentPage (or any page) with a RadScheduler in XAML, including at least one AgendaViewDefinition in ViewDefinitions:

<telerik:RadScheduler AppointmentsSource="{Binding Appointments}">
    <telerik:RadScheduler.ViewDefinitions>
        <telerik:AgendaViewDefinition />
        <telerik:DayViewDefinition />
    </telerik:RadScheduler.ViewDefinitions>
</telerik:RadScheduler>

3. Navigate to that page
4. Observe the unhandled exception

Expected Behavior:

The scheduler renders correctly with the AgendaViewDefinition, as it did in 13.0.0.

Actual Behavior:

An unhandled NullReferenceException is thrown:

System.NullReferenceException: Object reference not set to an instance of an object.
   at Telerik.Maui.Controls.Scheduler.SchedulerAgendaView.Init()
   at System.Threading.Tasks.Task.<>c.<ThrowAsync>b__124_0(Object state)
   at Microsoft.UI.Dispatching.DispatcherQueueSynchronizationContext.<>c__DisplayClass2_0.<Post>b__0()

Root Cause Analysis (via ILSpy decompilation):

Comparing the decompiled assemblies of 13.0.0 and 13.2.0 reveals a new override in RadScheduler introduced in 13.2.0:

// NEW in 13.2.0 — not present in 13.0.0:
protected override void OnPropertyChanged([CallerMemberName] string propertyName = null)
{
    base.OnPropertyChanged(propertyName);
    if (propertyName == "Parent" && Parent != null && !IsLoaded)
        UpdateActiveViewDefinition();
}

This causes the following call chain to be triggered during InitializeComponent() in the page constructor — before the page is attached to a window:

1. XAML parser adds RadScheduler to the page → Parent property changes
2. OnPropertyChanged("Parent") fires → UpdateActiveViewDefinition() is called
3. → ActiveViewDefinition = ViewDefinitions[0] (the AgendaViewDefinition)
4. → OnActiveViewDefinitionChanged() → content.Rebuild() (template already applied on WinUI3)
5. → SchedulerAgendaView.Model setter → Init() is called as async void
6. Inside Init(), after the first await, the continuation runs and DataBindingComplete fires
7. The completeHandler inside Init() calls:

((BindableObject)this).Dispatcher.Dispatch(async delegate { ... });

8. Dispatcher is null because the SchedulerAgendaView is not yet attached to a window → NullReferenceException

The exception is captured by the async void state machine and re-thrown via SynchronizationContext.ThrowAsync → DispatcherQueueSynchronizationContext.Post, which matches the observed stack trace exactly.

Why it worked in 13.0.0: UpdateActiveViewDefinition() was never called from OnPropertyChanged. It was only invoked after IsLoaded = true, at which point Dispatcher is guaranteed to be non-null.

Why the condition !IsLoaded is insufficient: Parent != null does not imply a window is present. During InitializeComponent(), the element has a parent in the logical tree but is not yet attached to any Window, making Dispatcher null on BindableObject.

Workaround:

Do not declare ViewDefinitions in XAML. Instead, add them programmatically in the page's Loaded event handler, at which point Dispatcher is guaranteed to be available:

private void OnPageLoaded(object sender, EventArgs e)
{
    if (scheduler.ViewDefinitions.Count == 0)
    {
        scheduler.ViewDefinitions.Add(new AgendaViewDefinition());
        scheduler.ViewDefinitions.Add(new DayViewDefinition());
        scheduler.ViewDefinitions.Add(new WeekViewDefinition());
        scheduler.ViewDefinitions.Add(new MonthViewDefinition());
    }
}

Suggested Fix:

Either:

Option A — Guard Dispatcher usage inside SchedulerAgendaView.Init():

// In completeHandler, before calling Dispatch:
if (((BindableObject)this).Dispatcher is { } dispatcher)
    dispatcher.Dispatch(...);

Option B — Guard UpdateActiveViewDefinition() in RadScheduler.OnPropertyChanged to only run when content (the internal RadSchedulerContent) has already been set (i.e., template was applied):

if (propertyName == "Parent" && Parent != null && !IsLoaded && content != null)
    UpdateActiveViewDefinition();

Option B is more conservative and closer to the original 13.0.0 behavior, since content being non-null implies the template has been applied and Dispatcher is available.

Environment: