5 ms·

I'm confused. Are you sure high DPI needs patching system controls to avoid pixelation? Doesn't dpiAwareness avoid the pixelation? I certainly haven't needed to

I'm confused. Are you sure high DPI needs patching system controls to avoid pixelation? Doesn't dpiAwareness avoid the pixelation? I certainly haven't needed to patch anything for this in the past. If you have an example you could point to, that would be great, since I don't know if I'm missing something here. Also, question: do you know of a good way to test for high-DPI mode on a low-DPI screen?

masfuerte 3y ago
You just need to add a manifest to your app indicating that you support high DPI. To test your app just change the DPI in the display settings.
- dataflow 3y ago
  I guess I was hoping for something little clunky than that, but thanks for the suggestion.
jansommer 3y ago
Nope, you get the pleasure of implementing dpi support yourself. https://building.enlyze.com/posts/writing-win32-apps-like-its-2020-part-3/ https://building.enlyze.com/posts/writing-win32-apps-like-it...
- dataflow 3y ago
  Thanks for the link. Glancing at it, I still don't see where there's a need to patch system controls for high DPI support, though. The closest thing I see there is for changing their fonts, but that seems different from patching them (no superclassing that I can see, etc.). Moreover, it's for dynamic DPI support (i.e. supporting DPI changes), not high DPI support. Is that what you were referring to?
  - jansommer 3y ago
    I think you should try a plain win32 program on a high dpi and just see for yourself.
    - dataflow 3y ago
      That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm kind of confused why you linked to an article that doesn't support your claim either. Hence why I'm asking you instead of spending hours trying to reproduce what you're saying.
      - jansommer 3y ago
        I don't know why you assume I'm here to give you helpful answers, but I'll bite. Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.
        dataflow 3y ago
        I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged. And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj https://imgur.com/a/Mb83tPj
        jansommer 3y ago
        That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.
        binjooou 3y ago
- GoblinSlayer 3y ago
  When you load a dialog from resource, windows scales it proportionally to specified font size (DS_FONT style).

masfuerte 3y ago

You just need to add a manifest to your app indicating that you support high DPI. To test your app just change the DPI in the display settings.

dataflow 3y ago
I guess I was hoping for something little clunky than that, but thanks for the suggestion.

jansommer 3y ago

Nope, you get the pleasure of implementing dpi support yourself. https://building.enlyze.com/posts/writing-win32-apps-like-its-2020-part-3/ https://building.enlyze.com/posts/writing-win32-apps-like-it...

dataflow 3y ago
Thanks for the link. Glancing at it, I still don't see where there's a need to patch system controls for high DPI support, though. The closest thing I see there is for changing their fonts, but that seems different from patching them (no superclassing that I can see, etc.). Moreover, it's for dynamic DPI support (i.e. supporting DPI changes), not high DPI support. Is that what you were referring to?
- jansommer 3y ago
  I think you should try a plain win32 program on a high dpi and just see for yourself.
  - dataflow 3y ago
    That's not exactly a... helpful answer. In fact I already have a Win32 (dialog-based, if that makes any difference) one that looks just fine on 200% DPI on Windows 10. All it required handling was scaling the obvious stuff (icon sizes, overall window size, etc.) and the manifest, nothing that required superclassing or otherwise patching common controls. i.e. I just haven't run into the problem you're mentioning. I'm kind of confused why you linked to an article that doesn't support your claim either. Hence why I'm asking you instead of spending hours trying to reproduce what you're saying.
    - jansommer 3y ago
      I don't know why you assume I'm here to give you helpful answers, but I'll bite. Try a combo box on high dpi. The arrow button gets a lot thinner than on 96 dpi.
      - dataflow 3y ago
        I didn't assume you'd give a helpful answer, but I didn't expect you to give that kind of an answer, either. You're always welcome not to respond if this is taking too much of your time. I figured maybe at least one of us would learn something about high DPI issues, hence why I engaged. And I did just try what you said and the combo box fine to me: https://imgur.com/a/Mb83tPj https://imgur.com/a/Mb83tPj
        jansommer 3y ago
        That is not the default Win32 combobox. I don't know what you're using, but it's not the plain c api.
        binjooou 3y ago
GoblinSlayer 3y ago
When you load a dialog from resource, windows scales it proportionally to specified font size (DS_FONT style).