If you want to handle DPI properly, and you want Windows, you probably want XAML, maybe WPF. WinForms does not handle DPI.

I'm assuming your requirements are that it's cross-platform?

http://www.mono-project.com/archived/winforms_designer/

It might be outdated, but perhaps it still works. I haven't tried it.

Actually not ... looking for one that sucks less.

specifically

• Easier to select/navigate nested layout panels
• better handling of DPI issues e.g. allow toggling between DPIs in design view.

MS's product is fine but seems like it hasnt been updated in ages and does have some problems. I can't get specific about the DPI stuff but it just feels like there are bugs there.

WinForms does not handle DPI.

It does, but the handling is pretty much awful. My best success with DPI on Winforms so far has been to explicitly disable it in the manifest, letting Windows scale up the application automatically. Results in some blur, but at least it's consistent. I don't remember exactly what was our primary issue, but I think it was related to custom drawing of controls. That part doesn't scale automatically or something while other things do.

Well, one of the few WinForms alternative that I know of would be GTK ... as to if it would be something usable here no idea, but not too sure how many winform alternatives there are out there.

Can't just switch to WPF because of a 100,000 lines of legacy code. This is for my day job ... some people are working on updating our UI by reskinning with custom controls in WinForms. Multi-DPI mostly works modulo problems. A big problem is VS Design View related. Sometimes when you just open a dialog VS will modify it to make it use the DPI you have opened it at or something like that. Not sure exactly ... just general diffiulties probably resulting from the fact that the last time anyone at Microsoft touched any of this stuff 90% of computers ran at 96 DPI.

Anyway usually there are competing products for everything, was surprised my Google Fu was not revealing even a single drop-ip replacement for the WinForms Forms editor so asked here.

How much of your 100,000 lines of code is actually interacting and caring about the UI? Win Forms has been an unsupported zombie for a while, which is why it has so many DPI issues. Long run, you're better off abstracting your code so that it's more shielded from UI changes, and then swapping to another UI framework. It'll be painful, and I'm sure management won't like it, however.

Can't just switch to WPF because of a 100,000 lines of legacy code. This is for my day job ... some people are working on updating our UI by reskinning with custom controls in WinForms. Multi-DPI mostly works modulo problems. A big problem is VS Design View related. Sometimes when you just open a dialog VS will modify it to make it use the DPI you have opened it at or something like that. Not sure exactly ... just general diffiulties probably resulting from the fact that the last time anyone at Microsoft touched any of this stuff 90% of computers ran at 96 DPI.

Anyway usually there are competing products for everything, was surprised my Google Fu was not revealing even a single drop-ip replacement for the WinForms Forms editor so asked here.

1. Do not modify WinForms stuff from computers with different DPI scaling enabled! It completely fucks up if you do that.
2. If it's an option for you, consider just disabling all DPI support and let Windows deal with it instead. If you do that, you can code as if DPI stuff doesn't exist and Windows will magically just scale up everything to match user settings.
   

   
     <asmv3:application>
       <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
         <dpiAware>false</dpiAware>
       </asmv3:windowsSettings>
     </asmv3:application>