- Adds a "resize reason" to platform `Resized` events
- Which is used by the auto-sizing code to determine whether to reset `SizeToContent`
- Also other improvements to the reset logic for `SizeToContent`:
- Don't reset it if the size hasn't changed
- Don't reset it if `CanResize == false`
- Only reset the dimensions whose size has changed
- Obsolete the `BeginAutoSizing`/`AutoSizing` feature in `WindowBase`
- Allow nested calls to `BeginAutoSizing` - previously it was called twice when showing a window on a secondary monitor and when the second `using` block exited it cleared the autosizing state despite the outer block not completing
- Call `SetWindowStartupLocation` within the auto-sizing block. Moving to a secondary monitor causes a resize message.
Had to remove syncing client size to `Width`/`Height` in `PopupRoot` bceause without the `SizeToContent` property it was impossible to tell whether its `Width`/`Height` came from a requested bound or from the actual window size.
Top-level controls cannot have a `Bounds` offset, and their `(Min)/(Max)/Width` and `(Min)/(Max)/Height` reflects the client size of the actual window, so don't need to be applied at the layout level.
Fixes#3784
This is a relic from when we were targeting a PCL profile that didn't have `System.ComponentModel.ISupportInitialize`. Now that we have that, use it instead.
This fixes the problem decribed in #1054 but I think there's something wrong with the way we handle top level layout anyway and it's going to need refactoring soon.
(cherry picked from commit 7337a90fc1)
Nikita Tsukanov
Dan Walmsley
Steven Kirk
Miha Markič
Nathan Garside
Dariusz Komosinski
Steven Kirk
CommonGuy
Stano Turza
José Pedro