Converting to v25.2.2

WindowTitleBar and OffScreenMargin

The WindowTitleBar typically hides the default window chrome to extend the client area (including the custom titlebar) into the native titlebar area. The Window.OffScreenMargin property is used on maximized windows, particularly those with the client area extended into the title bar, to ensure there is enough padding around the window content to avoid having it displayed off screen.

A new WindowTitleBar.CanConfigureWindowOffScreenMargin property has been added (which defaults to true). When enabled and the WindowTitleBar is hosted on a Window, the Window.OffScreenMargin property is automatically configured with a one-way binding to the Window.Padding property. As long as Window.Padding is used in the template of a Window control, any Window that uses a WindowTitleBar will, by default, display correctly when maximized.

When converting to this version, any explit use of the Window.OffScreenMargin property on a Window that also uses WindowTitleBar should be tested to ensure proper layout when maximized. In most scenarios, the use of OffScreenMargin can be removed. In some cases, this new feature may need to be disabled by setting WindowTitleBar.CanConfigureWindowOffScreenMargin to false.

WindowControl Active Border

In previous releases, the WindowControl BorderBrush property was set to an accent color when the control was active. This could be distracting in some scenarios (like showing a user prompt as an overlay) where there is only a single window at a time. With this release, the accent border is no longer applied by default when active.

The following style can be used to restore the accent brush when active:

<Style Selector="actipro|WindowControl:active">
	<Setter Property="BorderBrush" Value="{actipro:ThemeResource ControlBackgroundBrushSolidAccent}" />
</Style>

Define the style in Application.Resources to make it the default, or define in a control's Styles collection (e.g., Canvas.Styles) to have it applied only to children of that control.

Serialization Updates

The serialization framework primarily used by the Docking & MDI product's DockSiteLayoutSerializer has been updated to work without using XmlSerializer. The XmlSerializer class uses a reflection-based approach to determine which properties to serialize, and reflection is not compatible with ahead-of-time (AOT) compilation and trimming. To facility support for AOT and trimming, it has been replaced by a custom serialzer that uses a declarative approach to property discovery while also using the same XML format as XmlSerializer.

The following changes were made to XmlSerializerBase<T,U>, which is the base class for DockSiteLayoutSerializer:

• The CustomTypes property has been replaced by a RegisterType method. Instead of adding a Type to the CustomTypes collection, pass the type to the RegisterType method instead.
• The GetXmlSerializer method signature has changed.
  • It is no longer abstract and provides a default implementation that should satisfy most scenarios.
  • The primary reason this method was previously abstract was to allow the XmlSerializer to be initialized with custom types. All types used during serialization are now defined using the RegisterType method, and all of the registered types are passed through a new registeredTypes parameter (of type IEnumerable<Type>). This allows the default implementation of the method to fully initialize the XmlSerializer without requiring an override.
  • Any custom types that were previously added to XmlSerializer in the GetXmlSerializer method should, instead, be passed to the RegisterType method from within the constructor of the class. See note below about additional configuration necessary for declaring serialized properties.
  • After the above changes, any custom classes that override the GetXmlSerializer method should reassess if the override is still necessary.