Hi, thanks for posting.
Reading through your post, I can take a couple of things that I feel should be responded to separately here.
The first issue as I understand it is that you are frustrated that there are DPI issues in NCrunch, which given the number of updates and the effort we've put into the product, really shouldn't be the case. I realise this is especially annoying given that many setups now have at least some level of UI scaling, and I hear you. To help address this issue, I will share some more information about DPI in NCrunch in general, in the hope that it leads to a better understanding of the problems we have in this area.
One of the nice things about having users that are also developers is that people can often relate to some of the complications we need to deal with in a product like NCrunch. DPI is not one of these. When developing desktop software, in most cases the software is fixed to a specific version of .NET and uses one major form of UI tech (such as DPI, Winforms, MAUI, etc). By comparison in NCrunch, we need the system to work in 7 versions of Visual Studio (each of which runs on a different version of .NET). As much of NCrunch was built to work in VS2008, much of the UI is Winforms based, also interlaced with WPF. We're integrated with both VS and Rider, and in the case of the later, the UI is multi-process and must be beamed into the IDE through shared memory.
DPI compatibility problems vary by version of .NET. They vary by process lifespan. They vary by the workarounds introduced in hosting applications (like VS and Rider). They vary by versions of Windows. They are impacted by external tools and other plugins. It isn't possible to effectively automate testing for DPI scaling, and the platforms are constantly shifting. Part of the problem with DPI in general is that MS's approach to handling UI scaling at platform level has seen a number of changes as the problem domain has expanded. For example, newer versions of Windows allow scaling to be changed on a per-monitor basis, meaning that applications need to adapt their DPI scaling in real time as they are moved between screens. Some of this is handled by the platform transparently, with the rest of the bits needing to be picked up at application level.
I share these details not to make excuses, but to provide context. This is not a problem we can just solve. It's an endless game of whack-a-mole. Every time we think we've got it sorted, something we're integrated with changes and we end up chasing our tails until finally the problems get ironed out again.
For evidence of this, I would encourage you to look at the release notes of the builds we publish. Since V5.0 went out in March, we've already published 3 releases containing waves of fixes for DPI related problems, and we already have more in the pipe for the next upcoming build.
The second issue here is that you have a specific DPI related problem where NCrunch is not scaling windows according to your selected DPI. This issue is currently unknown to us. Can you share more details about your setup? Specifically, can you answer the following:
- Are you in VS or in Rider?
- Which build of Windows are you running?
- Do you have other plugins installed, and if so, does disabling them make any difference?
- Is your DPI setting consistent across all connected monitors?
- Which elements of NCrunch are not scaling correctly? Are there some parts that are working right?
