-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Open
Labels
🪲 bugProduct bug (most likely)Product bug (most likely)area-HDPI-SAIssues related to high DPI SystemAware modeIssues related to high DPI SystemAware modearea-controls-StripControlstenet-compatibilityIncompatibility with previous versions or with WinForms for .NET FrameworkIncompatibility with previous versions or with WinForms for .NET Framework
Milestone
Description
Presumably all versions:
- .NET Framework: 4.6.1 (tested)
- .NET Version: 5.0 (tested)
Problem description:
Originally reported in gitextensions/gitextensions#8680.
An application with two toolbars placed on the same lane, one after another. When the app is run in scaled environments (i.e. 125%+) the toolbars will get re-odered if the first toolbar becomes longer than the location of the second toolbar.
The same problem isn't observed at 100% scale factor, or if the repro app doesn't use its app.manifest.
Expected behavior:
The order of the toolbars set at the design time must be preserved.
A workaround is to remove all toolbars after InitializeComponent(); and add them back in the correct order, e.g.:
public FormBrowse()
{
InitializeComponent();
this.toolPanel.TopToolStripPanel.Controls.Clear();
this.toolPanel.TopToolStripPanel.Controls.Add(this.ToolStripFilters);
this.toolPanel.TopToolStripPanel.Controls.Add(this.ToolStripMain);
}Minimal repro:
- clone https://github.com/RussKie/Test-ToolStripOrder
- run the app at 100% - observe
ToolStripMainbeforeToolStripFilters - run the app at 150%+ - observe the reverse order of toolbars
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
🪲 bugProduct bug (most likely)Product bug (most likely)area-HDPI-SAIssues related to high DPI SystemAware modeIssues related to high DPI SystemAware modearea-controls-StripControlstenet-compatibilityIncompatibility with previous versions or with WinForms for .NET FrameworkIncompatibility with previous versions or with WinForms for .NET Framework


