Skip to content

Allow for waiting for DialogHost animations. - #4083

Draft
Keboo wants to merge 1 commit into
masterfrom
issue4017
Draft

Allow for waiting for DialogHost animations.#4083
Keboo wants to merge 1 commit 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.

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.

@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 on lines +35 to +41
currentState = _visualStateGroup.CurrentState.Name;
if (currentState == state)
{
_visualStateGroup.CurrentStateChanged -= stateChanged;

return Task.CompletedTask;
}

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.

Don't you already have this guard in line 17-18? Is there a scenario where the current state can change between line 18 and here?

}

public Task WaitForOpened(CancellationToken cancellationToken = default)
=> _visualStateMonitor?.WaitForState(OpenStateName, cancellationToken)

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.

Regarding whether cancellationToken should be required: How about setting a reasonable self-cancelling token (say 5 seconds) if one is not supplied by the caller? I guess what you're trying to avoid by making it mandatory is the infinite hang waiting for a state change that never occurs? A reasonable default token would do that too I guess.

My assumption here is that the caller would only call these methods right before opening/closing the DialogHost and therefore the timeout should just be slightly longer than the duration of the animation. I hope my assumption is correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants