winforms icon indicating copy to clipboard operation
winforms copied to clipboard

StatusStrip button next to SizingGrip is now missing

Open rickbrew opened this issue 6 months ago • 15 comments

.NET version

10.0 Preview 6

Did it work in .NET Framework?

Yes

Did it work in any of the earlier releases of .NET Core or .NET 5+?

This works in .NET 9, and it was working fine in .NET 10 Preview 5

Issue description

I have a StatusStrip in my app, and at the bottom right there are some zoom-related controls and then the sizing grip.

Since .NET 10 Preview 6, the last of my buttons, which performs a Zoom In operation, is missing.

I'm guessing it's related to #13620 by @KlausLoeffelmann, but it's also similar to #11208.

Steps to reproduce

Launch Paint.NET using .NET 10 Preview 6 (I can provide binaries, and/or access to the repository here on GitHub)

It should look like this:

Image

Instead, it looks like this. Note that the button with the hourglass and plus sign is missing, which is the "Zoom In" button:

Image

rickbrew avatar Jul 18 '25 22:07 rickbrew

I was able to verify that this is a new bug that was introduced between .NET 10 Preview 5 and Preview 6

I have a build of my app from July 7th which is using .NET 10 Preview 5 and it does not exhibit this bug. If I do a git checkout to the commit that lines up with that build, but build it today using .NET 10 Preview 6, the zoom button is now missing.

rickbrew avatar Jul 18 '25 22:07 rickbrew

Hey Nick,

it's funny, because just the other day I thought the same, namely the sizing grip, which I am rendering a bit different to address higher scaling settings and the rounding corners, was the culprit.

Meanwhile I am thinking, it's a red herring, and this may not even be a regression. I assume, you designed this or last saved it in > 125% scaling? Could you set the Display settings to 125%, log off and in again, Open the tool window in the Designer, dirty the Form/UserControl, save it, and try it again?

Could you then reset the Scaling to whatever had it before, and - without changing anything in that Form, run it again?

Do you see anything unexpected?

KlausLoeffelmann avatar Jul 19 '25 06:07 KlausLoeffelmann

DPI scaling does change things -- I run at 150%. If I change it to 125%, it's still hidden.

At 100% though it becomes visible:

Image

rickbrew avatar Jul 20 '25 19:07 rickbrew

I just tested with .NET 8, and had similar results, albeit with totally different thresholds. The Size Grip has a bit to do with it, but not the revamped rendering of it.

If I disable the rendering if the Grip, in some HighDPI modes it's then rendering correctly, but it is not really predictable.

A dummy item following the last one is the best chance for an ad-hoc work around, I suppose.

What's funny though: The moment you select one of the items in the Designer, the toolbar is rendering everything correctly. Can you repro that one?

I am working on the niche-dark-mode-issues today; if this is a quick fix, maybe I can include this.

I am more convinced now that Dark Mode here is a red herring. It might be a trigger in that some things I render slightly differently than before. I think it's rather a fallout of the Layout engine changes we made some time ago.

@merriemcgaw FYI.

KlausLoeffelmann avatar Jul 21 '25 17:07 KlausLoeffelmann

The moment you select one of the items in the Designer, the toolbar is rendering everything correctly. Can you repro that one?

I haven't used the designer since about 2005 or 2006 :) None of my UI will load correctly in the designer. Side note, I hope that the rewritten WinForms Designer can remain an optional toggle once it's promoted past "experimental," as it is a giant PITA to double-click on a code file and have it try to boot up the designer and then close the tab and slowly right click -> open width -> code editor. Major productivity loss for me since this would be happening many times per hour. I'll have to file an issue at some point.

I am more convinced now that Dark Mode here is a red herring.

PDN is using its own dark mode implementation, I'm not yet using any of the new WinForms Dark Theme stuff. So I agree that it is probably a red herring.

rickbrew avatar Jul 22 '25 20:07 rickbrew

Side note, I hope that the rewritten WinForms Designer can remain an optional toggle once it's promoted past "experimental," as it is a giant PITA to double-click on a code file and have it try to boot up the designer and then close the tab and slowly right click -> open width -> code editor. Major productivity loss for me since this would be happening many times per hour. I'll have to file an issue at some point.

@Shyam-Gupta do you think this is something we can enable once we are ready to remove the Preview checkbox? If so, let's get an issue in the designer repo and get it done with the removal of "preview checkbox".

merriemcgaw avatar Jul 23 '25 19:07 merriemcgaw

Yes, this is very much feasible. I will create an issue for it in the designer repo.

Shyam-Gupta avatar Jul 23 '25 20:07 Shyam-Gupta

@KlausLoeffelmann do you need anything more from me for this bug?

rickbrew avatar Aug 08 '25 03:08 rickbrew

Hi @rickbrew

@KlausLoeffelmann suggested an existing option in VS that we can use to open the designer in code view by default. It is available in Solution Explorer -> Select Form1.cs -> Right click -> Open With...

In the dialog you can set C# Editor to be the default. After that every time you double click on any Form.cs, it will open in code editor instead of designer. Would that address your requirement?

Image

Shyam-Gupta avatar Aug 12 '25 20:08 Shyam-Gupta

Would that address your requirement?

Yeah that seems perfect 👍

rickbrew avatar Aug 12 '25 22:08 rickbrew

btw if I remove the status grip (SizingGrip = false), the zoom in button does correctly appear. So at least I sort of have a workaround for now.

Image

rickbrew avatar Aug 13 '25 00:08 rickbrew

So, the workaround I use right now in my own Apps is defining a bit of a larger right Margin for the last Item to display.

The problem is the scaled margin in a scaled HighDpi scenario, by which, I assume, we're not reducing the internal used TableLayout client size (and never have), which then in turn means the last item hit the SizeGrip and gets kicked out.

Poor thing.

I am not sure, how courageous I am to "fix" this, because I might break workarounds. (@merriemcgaw, could we quirk this?)

I also don't know, why we're not PropertyBrowser-exposing Padding for the StatusStrip, btw, because that would come in handy for such cases now.

I just finished the open DarkMode issues for RC1, and also took Dark Mode and the remaining Async APIs out of experimental mode.

Let me catch my breath a bit, and then I'll think about this a bit more. I think I can argue this could make the bar for an RC2 fix, because this clearly goes into A11Y territory.

KlausLoeffelmann avatar Aug 17 '25 06:08 KlausLoeffelmann

Oh, and @rickbrew:

If your time allows, would you mind running PDN against the nightly RC2 build and see, if you're good with it? 🥺

PDN is using its own dark mode implementation, I'm not yet using any of the new WinForms Dark Theme stuff. So I agree that it is probably a red herring.

Ping me directly at firstname.lastname at Microsoft.com, if you like, to sync what improvements you'd need?

KlausLoeffelmann avatar Aug 17 '25 06:08 KlausLoeffelmann

If your time allows, would you mind running PDN against the nightly RC2 build and see, if you're good with it?

No luck

Image

I can give you access to a mirror of the PDN repo, it's already set up and approved for MSFT employees

rickbrew avatar Aug 18 '25 16:08 rickbrew

Any news on this? Still seeing it in 10-rc2

rickbrew avatar Nov 09 '25 18:11 rickbrew