And this is where the problems start! Your Delphi applications will probably look super (small or stretched) ugly if the application is not DPI aware or will look messed up if the controls you use do not know how to scale themselves (and the application is DPI aware). That’s supper small and not usable! This is the reason why Windows turns on DPI scaling by default so stuff on such screens becomes bigger (except your 16×16 px glyph on that button which remains 16×16 px and is barely visible, ha!). Just imagine a standard glyph of 16×16 pixels on your standard TBitBtn.
If you think Full HD (1920 x 1080) is big, what do you then think of 3480 x 2160 pixels? What’s worst is that those high resolutions tend to be used on small laptops (e.g. The thing is that today’s laptops and desktops come standardly with (very) high resolution screens. If you do not know what I’m talking about then you are kind of blessed.īut, sooner or later you will find yourself searching the Internet for keywords including: Delphi, 4K displays, high DPI, form / control scaling / sizing, DPI awareness, PixelsPerInch, DPI virtualization in Windows and alike. Alas, what takes time are those few (third party AND VCL) controls that refused to be properly scaled so you really have to test on various screen sizes and various DPI levels. There are really just a few things that need to be done in your Delphi application to make it properly DPI aware. It was not a too hard job – it just took a lot of time and experimenting (read: fixing) how the UI of the application appears on various 4K displays having various settings for “ Make text and other items larger or smaller” (Windows Vista/7/8), which is the same as “ Set a custom scaling level” (Windows 10).Īctually, saying that “high-dpi enabling” took a few weeks is wrong. Woohoo! After a few weeks of struggle I’ve finally high-dpi enabled my used-across-the-globe Delphi application.
0 kommentar(er)
