[API Proposal] Make ToolStrip.ImageScalingSize participate in AutoSize layout under VisualStylesMode.Net12

[KlausLoeffelmann]

Background and motivation

ToolStrip.ImageScalingSize influences image rendering today, but it does not participate in AutoSize layout in the intuitive way developers expect when no image-bearing item has yet been measured. This creates confusing runtime and Designer behavior: changing the property can fail to update ToolStrip bounds until image content participates in layout or the control is recreated.

The Designer hosts real WinForms controls, so this should be corrected in runtime layout rather than through Designer-only shadow state or recreation.

Companion Symbol API proposal: #14921.

API Proposal

No new ToolStrip property is proposed. Under VisualStylesMode.Net12:

• when AutoSize == true, ImageScalingSize contributes to the ToolStrip cross-axis preferred-size calculation even when no current item contains an image;
• for horizontal ToolStrips, ImageScalingSize.Height contributes to minimum content height;
• for vertical ToolStrips, ImageScalingSize.Width contributes to minimum content width;
• changing ImageScalingSize invalidates preferred-size/layout state and immediately remeasures an AutoSize ToolStrip;
• existing visual-style modes retain current behavior.

The metric is an input, not the final control bounds. Normal layout still accounts for font/text, padding, margins, grip/chrome, renderer metrics, separators, arrows, and min/max size.

Current source evidence:

• The setter only performs layout work when items exist: ToolStrip.ImageScalingSize.
• Preferred image size is derived from actual image/image-list participation: ToolStripItem.PreferredImageSize.
• Menu layout consumes ImageScalingSize inside the image path: ToolStripMenuItemInternalLayout.
• Dropdowns already delegate internal image scaling metrics to their owner: ToolStripDropDown.ImageScalingSizeInternal.

The default remains 16×16; this proposal changes measurement semantics only.

Open questions:

1. Should an empty AutoSize ToolStrip use ImageScalingSize as a cross-axis minimum?
2. Should MenuStrip, StatusStrip, ContextMenuStrip, and generated dropdowns inherit this uniformly?
3. How should ImageScaling = None interact with the strip-level layout hint?
4. Is a named VisualStylesMode.Net12 member the right compatibility gate, or should the behavior follow Latest differently?

API Usage

var toolStrip = new ToolStrip
{
    AutoSize = true,
    ImageScalingSize = new Size(24, 24),
};

// Under VisualStylesMode.Net12, this immediately remeasures the cross-axis
// even before an image-bearing item exists.
toolStrip.ImageScalingSize = new Size(32, 32);

Alternative Designs

• Add a second layout-hint property. This duplicates intent and complicates the Designer/API model.
• Change behavior in all visual styles. This risks existing application layout without a compatibility gate.
• Implement a Designer-only shadow property or recreate ToolStrips. This splits runtime/design-time behavior and leaves the runtime bug intact.
• Document current behavior. This preserves an unintuitive propagation model and Designer roundtrips.

Risks

• AutoSize bounds can change for applications opting into VisualStylesMode.Net12.
• Custom renderers and derived ToolStrips must continue to account for chrome and other content requirements.
• DPI rounding and min/max constraints must remain stable.
• MenuStrip, StatusStrip, and dropdown specializations may need targeted layout adjustments rather than a single base-class change.

Will this feature affect UI controls?

Yes. The test matrix should include:

• horizontal and vertical orientation;
• empty, text-only, image-bearing, and mixed image/symbol strips;
• runtime changes before and after population;
• ImageScaling values SizeToFit and None;
• AutoSize true and false;
• MinimumSize / MaximumSize, padding, grip style, fonts, and custom renderers;
• ToolStrip, MenuStrip, StatusStrip, ContextMenuStrip, dropdowns, and custom derivatives;
• 100%, 150%, 200%, and per-monitor DPI changes;
• Designer property edits and serialization;
• legacy visual-style modes remaining unchanged.