Don't throw exceptions on back-to-back window deactivations#23519
Conversation
…is valid behavior on platforms such as Windows.
Foda
changed the title
PureWeen
left a comment
PureWeen
left a comment
There was a problem hiding this comment.
Does Activated ever get fired? Like, does activated fire once and deactivated is fired twice?
Or does the window just get created and deactivated is called twice?
Would a possible fix be to not even call deactivated at all on windows for this scenario?
Like, are these deactivate calls that come from the windows platform useful at all?
Just validating if we're fixing something here that should just be a platform specific modification vs an xplat one.
| !_isActivated) | ||
| { | ||
| // Don't invoke deactivated event if we're not activated. It's possible we can | ||
| // recieve this event twice if we start more than one process at a time |
There was a problem hiding this comment.
Why would two processes be using the same MauiWinUIWindow?
There was a problem hiding this comment.
Ah, they're not the same MauiWinUIWindow: starting any process that has a window will send a window message back to the window of the process that started it:
|
Thank you for adressing this! |
samhouts
added
fixed-in-net9.0-nightly
4 participants
Description of Change
Don't throw exceptions on back-to-back window deactivations as this is valid behavior on platforms such as Windows (should we limit this change to just Windows?)
This is because it's possible to receive 2 "deactivate" window messages in a row if 2 child process windows are created rapidly. Each deactivate message has a parameter of the handle for the new window being created.
Issues Fixed
Fixes #22406