Allow for waiting for DialogHost animations. by Keboo · Pull Request #4083 · MaterialDesignInXAML/MaterialDesignInXamlToolkit

Keboo · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 · 2026-08-21T07:10:43Z

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:

Are the WaitFor* methods named properly?
Tests, need to have them. Will be impossible to test race conditions reliably, but happy path should be there.
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

Only some minor comments. Looks good to me though.

corvinsz

Looks great already, good idea.

Are the WaitFor* methods named properly?

LGTM

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

Agree

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?

publicTaskWaitForClosed(TimeSpantimeout){usingCancellationTokenSourcects=new(timeout);returnWaitForClosed(cts.Token);}

~~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?

publicstaticTaskWaitForOpened(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForOpened(cancellationToken);}publicstaticTaskWaitForClosed(object?dialogIdentifier=null,CancellationTokencancellationToken=default){varinstance=GetInstance(dialogIdentifier);returninstance.WaitForClosed(cancellationToken);}// usage:awaitDialogHost.Show(...);awaitDialogHost.WaitForClosed();

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 requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Keboo requested review from corvinsz and nicolaihenriksen August 21, 2026 07:10

nicolaihenriksen approved these changes Aug 22, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs
Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs

corvinsz reviewed Aug 25, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/Internal/VisualStateMonitor.cs Outdated

corvinsz reviewed Aug 26, 2026
View reviewed changes

Comment threadsrc/MaterialDesignThemes.Wpf/DialogHost.cs Outdated

Keboo added 3 commits August 27, 2026 21:41

Keboo force-pushed the issue4017 branch from 1ede98f to 6994720Compare August 28, 2026 05:23

Keboo marked this pull request as ready for review August 28, 2026 05:31

Keboo added enhancement release notes Items are likely to be highlighted in the release notes. labels Aug 28, 2026

Keboo added this to the 5.3.3 milestone Aug 28, 2026

Keboo merged commit 0294e96 into masterAug 28, 2026
2 checks passed

Keboo deleted the issue4017 branch August 28, 2026 05:48

Keboo modified the milestones: 5.3.3, 5.4.0 Aug 28, 2026

corvinsz mentioned this pull request Aug 28, 2026
DialogHost.WaitFor* methods not waiting for animation to finish #4086
Open

Uh oh!

Conversation

Keboo commented Aug 21, 2026

Uh oh!

nicolaihenriksen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

corvinsz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Keboo commented Aug 21, 2026

Uh oh!

nicolaihenriksen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

corvinsz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Keboo commented Aug 21, 2026

Uh oh!

nicolaihenriksen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

corvinsz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

Keboo commented Aug 21, 2026

Uh oh!

nicolaihenriksen left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

corvinsz left a comment •
edited
Loading

corvinsz left a comment •
edited
Loading

corvinsz left a comment •
edited
Loading

corvinsz left a comment •
edited
Loading

corvinsz left a comment •
edited
Loading