Window.SizeChanged Event

Definition

Namespace:

Windows.UI.Xaml

Occurs when the app window has first rendered or has changed its rendering size.

public:
 virtual event WindowSizeChangedEventHandler ^ SizeChanged;

// Register
event_token SizeChanged(WindowSizeChangedEventHandler const& handler) const;

// Revoke with event_token
void SizeChanged(event_token const* cookie) const;

// Revoke with event_revoker
Window::SizeChanged_revoker SizeChanged(auto_revoke_t, WindowSizeChangedEventHandler const& handler) const;

public event WindowSizeChangedEventHandler SizeChanged;

function onSizeChanged(eventArgs) { /* Your code */ }
window.addEventListener("sizechanged", onSizeChanged);
window.removeEventListener("sizechanged", onSizeChanged);
- or -
window.onsizechanged = onSizeChanged;

Public Custom Event SizeChanged As WindowSizeChangedEventHandler 

Event Type

WindowSizeChangedEventHandler

Remarks

This event occurs whenever there are changes in the Bounds values for the app window. This might be because the user resizes your app or changes the display orientation. Another trigger is if the user moves your app to a new display that has a different resolution and the app window expands to fill it.

Window.SizeChanged is the event to handle in order to detect that the user has deliberately resized your app or rotated the display on a PC that detects orientation. You may want to detect that the app window has changed from landscape to portrait orientation or vice versa. The app window orientation might influence how you want the individual controls within the app window to appear. For example, you might want to display data lists in a ListView for portrait orientation, but in a GridView for landscape orientation. Typically you would compare the ratio of Window.Current.Bounds.Width to Window.Current.Bounds.Height in order to determine the orientation based on the Bounds, and you'd do this whenever Window.SizeChanged fires. Exactly how you interpret width/height ratios is up to you.

If you're attaching handlers for Window.SizeChanged at the Page level within a handler for the FrameworkElement.Loaded event, you should detach those handlers in a FrameworkElement.Unloaded event handler from that Page. The Window.Current instance remains active between page navigations and should only have a handler active for the most current page code.

A Window.SizeChanged handler is not how you enforce the minimum size that your app can be resized to. That's controlled by the app manifest. However, your logic for changing the visual states should be able to load a state that's designed for the minimum width you intended, and you'd typically use the Bounds values and Window.SizeChanged handling to detect when the app window is using minimum width.

For more info on how to use Window.SizeChanged to detect changes in the app window environment and load the appropriate visual states for your app, see Quickstart: Designing apps for different window sizes.

There's another event named SizeChanged that exists on FrameworkElement derived types (Window is not a FrameworkElement type). FrameworkElement.SizeChanged events might fire in many of the same circumstances that cause Window.SizeChanged to fire. An app window size change can cause the root visual element (typically a Page or panel) to change its size. This sets off a cascade of layout invalidations for any the subelements that are using adaptive layout to fill available space. Each element that has new dimensions because of a layout pass will fire its own FrameworkElement.SizeChanged event.

See also

• Bounds
• Content
• SizeChanged
• WindowSizeChangedEventArgs
• Quickstart: Designing apps for different window sizes