ikjadoon

Oh, that's great to hear that it's on your radar. Thank you for the reply and update. Very understandable; v.4.4 looks to be a massive upgrade, so this is a bit of a lower priority. Oh, yes: the translation of the text. I noticed the Cowdin thread earlier. I wish I knew more languages fluently enough to help translate. Microsoft does have the "Edit with Paint" text by default in Windows 11 which I assume is a verified-good translation. If that's the string needed, I think I could spin up Windows 11 VM's and just grab that string from Microsoft's built-in different language packs—just replace "Paint" with "Paint.NET". I'll see about making a Crowdin account--if I'm barking up the right tree here.

I might've missed the discussion on this (search only brought up this non-Paint.NET generic Windows 11 discussion in Off-Topic). My apologies if this has already been requested, though I didn't see it on the Roadmap, either. Currently, Paint.NET on Windows 11 has lost its image context menu option in the Windows 11 redesign. The only way to access Paint.NET's editor in Windows 11 now is by first hovering over Open With -> scrolling to Paint.NET -> clicking Paint.NET. I'd love to have the old single-click "Edit" menu make a return to Paint.NET. The feature request: add "Edit with Paint.NET" as a single context menu option, using Microsoft's latest guidelines: I'm not sure if this is possible with how Paint.NET is written, but I hope it can be added in some future Paint.NET update. For example, WinRAR has recently added this option in their latest updates: However, because they have multiple options, it's been forced into a cascading menu (as required by Windows 11). I think Paint.NET will be better served with a single context menu entry (or allow for both single vs cascaded options).

Thank you kindly for the update. No worries: take your time. Paint.NET is certainly not the only application with those updates in the backlog. Thank you for having it on your radar. In the mean time, I've changed to 2x 1440p monitors to avoid this issue (and others!), so I'm good on this front as well. Thank you again for your thoughtful replies & candid efforts. I'm off to more excellent editing 😎

No, none at all: agreed, Windows does it more than well enough. I'd consciously avoid windows (lowercase 'w') management software just for that reason: I'm already feeling anxious just thinking of how many programs don't play well. On the NVIDIA GT 710 (not Quadro), it's just the NVIDIA drivers: I long uninstalled their GeForce Experience bloatware. // However, it does look like it's something much deeper than Paint.NET. I ran through my programs list and found these applications exhibited the bug: Notepad++ 32-bit 7.9.1 Paint.NET 4.2.14 7-zip x64 19.00 Most Adobe CC software (latest) Apple iTunes 12.11.0.26 (does not exhibit hover symptom, but still can click behind) These programs did not exhibit the bug: Chrome 87.0.4280.141 All Office applications (latest) Adobe Illustrator CC (latest; 25.1) Audacity 2.4.2 Noting your DPI test, I used Task Manager's DPI Awareness. The bug almost always appears in programs with "DPI Awareness = System". The safe applications are set to "DPI Awareness = Unaware" or "DPI Awareness = Per-Monitor (v2)" like Chrome, which is a mix of unaware and per-monitor v2. I'll run some more tests and see what can be done. But, yes: I think this bug report can be closed on Paint.NET's end as it's not just Paint.NET & Notepad++, but a whole bevy of applications. Though half of me thinks that it's time to upgrade to 2x 1440p monitors, haha...

Ah, hello! Thank you so much for developing Paint.NET. It's saved my life many times; I've bought the Store version, but prefer the *.exe for some flexibility purposes. Thank you. And you're exactly right. With more DPI testing & switched around the monitors, the bug only reproduces 1) if the DPIs are not equal and 2) on the secondary monitor. Monitor 1 (primary) : 1440p @ 125% DPI Monitor 2: 1080p @ 100% DPI (bug appears here) Monitor 1 (primary) : 1440p @ 100% DPI Monitor 2: 1080p @ 125% DPI (bug appears here) Monitor 1 : 1440p @ 125% DPI (bug appears here) Monitor 2 (primary) 1080p @ 100% DPI Monitor 1: 1440p @ 100% DPI (bug appears here) Monitor 2 (primary) : 1080p @ 125% DPI Unfortunately, I'm at 125% and 100% DPI (the recommended DPI by Windows for the 1440p & 1080p displays, respectively). I understand if this bug is a corner case, low-hit-rate by Paint.NET users. It's not a serious bug, but perhaps noted for the future, as seemingly all of my other applications (except notably Notepad++) don't exhibit the bug on split-DPI configurations. Ah, fair. Are you running two different DPIs?

Paint.NET: version 4.2.14 (final 4.214.7601.39231) OS: Windows 10 Pro x64 20H2 (19042.746) Display 1: 2560x1440 @ 125% DPI / Intel i5-8600K iGPU, driver 27.20.100.9126 Display 2: 1920x1080 @ 100% DPI / NVIDIA GT 710 dGPU, driver 27.21.14.6109 (problem occurs only on this monitor) What should happen: when Paint.NET is maximized, its window should extend to the top of the monitor. So, moving your cursor to the top-right should always hit the red "X" close button. What actually happens: Paint.NET leaves an unusual gap at the top and I often click the window behind Paint.NET when Paint.NET is in fact maximized. This 1px gap is not consistent, but is sometimes there and sometimes not. The easiest way to show this is 1) open Paint.NET on a 2nd monitor, 2) maximize Paint.NET, 3) run your mouse at the top-right of your window. Google Chrome Maximized (version 87.0.4280.141) Paint.NET Maximized (version 4.2.14) In some regions, Paint.NET is now hovering over the program behind it and thus you end up misclicking. This bug is not an animation bug; when Paint.NET loses focus in the animation, so has your mouse. The flickers are when you're hovering over the window behind Paint.NET. This bug also occurs with NotePad++ (someone reported it in August 2020), so I wonder if there's a framework or library that's the same between the two applications.