Skip to content

Allow for waiting for DialogHost animations. - #4083

Merged
Keboo merged 3 commits into
masterfrom
issue4017
Aug 28, 2026
Merged

Allow for waiting for DialogHost animations.#4083
Keboo merged 3 commits into
masterfrom
issue4017

Conversation

@Keboo

@Keboo Keboo commented Aug 21, 2026

Copy link
Copy Markdown
Member

Potential Fix for #4017

Introduces WaitForOpened and WaitForClosed methods on DialogHost to enable asynchronous waiting for the completion of the dialog's visual state transitions. This provides more precise control for executing logic precisely after the dialog has fully opened or closed, rather than just when events are dispatched.

Outstanding items:

  1. Are the WaitFor* methods named properly?
  2. Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
  3. Should the CancelationToken int he WaitFor* methods be required rather than optional?

Updates the DialogSession to expose the parent DialogHost instance, facilitating access to these new awaitable methods.

@nicolaihenriksen nicolaihenriksen left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only some minor comments. Looks good to me though.

Comment thread src/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment thread src/MaterialDesignThemes.Wpf/DialogHost.cs

@corvinsz corvinsz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great already, good idea.

  1. Are the WaitFor* methods named properly?

LGTM

  1. Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.

Agree

  1. Should the CancelationToken int he WaitFor* methods be required rather than optional?

Besides what @nicolaihenriksen already mentioned (using a default timeout if none is supplied), what about adding an overload that takes a TimeSpan?

public Task WaitForClosed(TimeSpan timeout)
{
    using CancellationTokenSource cts = new(timeout);
    return WaitForClosed(cts.Token);
}
  1. Shouldn't the WaitFor* methods be static, or am I misunderstanding the design of the public API?
    Edit:
    I overlooked your example and now understand how you intended the API: register for DialogClosingEventHandler and call await eventArgs.Session.DialogHost.WaitForClosed(); in the handler.
    To improve discoverability (and maybe developer experience?), thoughts on adding static methods for WaitFor* like so?
public static Task WaitForOpened(object? dialogIdentifier = null, CancellationToken cancellationToken = default)
{
    var instance = GetInstance(dialogIdentifier);
    return instance.WaitForOpened(cancellationToken);
}

public static Task WaitForClosed(object? dialogIdentifier = null, CancellationToken cancellationToken = default)
{
    var instance = GetInstance(dialogIdentifier);
    return instance.WaitForClosed(cancellationToken);
}

// usage:
await DialogHost.Show(...);
await DialogHost.WaitForClosed();

Comment thread src/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated
Comment thread src/MaterialDesignThemes.Wpf/DialogHost.cs Outdated
Keboo added 3 commits August 27, 2026 21:41
Introduces `WaitForOpened` and `WaitForClosed` methods on `DialogHost` to enable asynchronous waiting for the completion of the dialog's visual state transitions. This provides more precise control for executing logic precisely after the dialog has fully opened or closed, rather than just when events are dispatched.

Updates the `DialogSession` to expose the parent `DialogHost` instance, facilitating access to these new awaitable methods.
The `VisualStateMonitor` failed to correctly identify the 'Open' and 'Closed' states due to an incorrect type cast (`OfType`) when retrieving state names. This prevented the `WaitForOpened` and `WaitForClosed` methods from functioning as intended. This change corrects the type to `VisualState` to ensure proper state detection.

Adds a new UI test to confirm the `WaitForClosed` method completes reliably.

Fixes #4017.
Ensures `WaitForOpened` and `WaitForClosed` handle cancellation tokens correctly by unsubscribing from `VisualStateGroup` events. This prevents potential resource leaks and ensures reliable cancellation.

Adds tests to confirm that waiting methods complete immediately if the dialog is already in the target visual state, enhancing predictability. This also validates the overall reliability of asynchronous state transitions.
Fixes #4017.
@Keboo
Keboo marked this pull request as ready for review August 28, 2026 05:31
@Keboo Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026
@Keboo Keboo added this to the 5.3.3 milestone Aug 28, 2026
@Keboo
Keboo merged commit 0294e96 into master Aug 28, 2026
2 checks passed
@Keboo
Keboo deleted the issue4017 branch August 28, 2026 05:48
@Keboo Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement release notes Items are likely to be highlighted in the release notes.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants