I found that some of the controls are not supporting high dpi screens. There are different case scenarios:
1 - Open on 96dpi (100%) screen and move to higher dpi screen (say 250%).
2 - Open on 250% screen and move to 100% screen.
It's fairly easy to add support once you make a helper class but both those cases have to be tested. (plus testing when it's opened on a 250% and used on 250%).
Unfortunately a couple of the TMS components I use don't work even when opened on 250% and used on 250%. So people with laptops and screens using highdpi can't use the application. That is a HUGE problem since most new tablets/laptops (one example, surface) use the high dpi setting. Changing to dpi unaware application means the icons look ugly on the new systems.
Can you guys prioritize adding high-dpi support to the components? At least those listed in the subject, TAdvTreecomboBox, TParamListBox. I also use a TGradientLabel and TVrIndicator but those seem to work.
Actually:
1 - Open on 96dpi (100%) screen and move to higher dpi screen (say 250%) then back to 100%
2 - Open on 250% screen and move to 100% screen then back to 250%
There may be a few TMS VCL components which still do not handle DPI correctly and, as you say, need a workaround; but my app with a ParamListBox works as expected and allows its window to be be moved between different DPI monitors without any surprises, and without needing any ...DPIchanged events.
Start on 96dpi 100%, move to 250% - try to use the spin controls more than 1 time. Then move back to 100%, the line spacing is wide, back to 250% wide lines again, if you make changes then brings the spacing between the next one ok but others remain extra high (I don't have the system up right now, just going from memory). But the spin / edit issue may be something that happens in high dpi by default ... first time enough size but second time not wide enough to enter text (and on spins there are only up/down button, can't see text). Also note this is when using Per Monitor V2 and not none-dpi aware mode where windows handles most things by scaling.
Actually the TVrIndicatr also seems to have some problem when main window is on 250% the window with it opens on 100% then attempt to move from 100% to 250% gives an exception about out of resources. If I open it on a 250% screen then it works, move to 100% works, back to 250% same error. This control on design view is 114x9 (left:88 and anchors: left, top, right). See attached pic (I'm not sure why C++Builder debugger is so bad on things like providing the parameter values).
I retested TvrIndicator here again with different IDEs, different monitor and DPI combinations, but I couldn't see any error here. So, I'm not sure what is causing this. What IDE do you use and have you applied the latest updates/patches to the IDE?
It has something to do with the align processing it comes in to TBitmap.SetSize with the height == 22 and width == -36. I'll try to make a test project from another test project I already have ...
I added it - the LED test button (move from 100% to 250%). The weird thing is it only occurs if that TLabeledEdit also exists.
Just want to ensure you see the TAdvTreecomboBox & TParamListBox issues moving between screens (back and forth 100% to 250%). Also on the TParamListBox, you may be able to open a spinner or edit control, etc.. first time and see numbers, but second time you can't see anything, no edit field (too small). On that test project I sent, not sure if it is C++Builder itself or something with TvrIndicator, I sent test project to embarcadero as well in case on their end (maybe if so, you can too).
I retested this here once more, including with our parameter controls demo, on RAD Studio 11.3, but I could not see issues here with per monitor high DPI handling.
Make sure you're using per monitor v2 on your project.
For the parameter control, move it from the 100% to to 250%, change a spinner, first time you may be able to see the number, accept the change, then open it again, you don't see anything. Now move it from the 250% back to 100%, each line item is extra high with a lot of spacing between, make a change to a line item, that line then reverts back to the correct height.
For the tree control, move it then attempt to open the dropdown, it's on top (instead of bottom) and no items can be seen (and extra long apparently).
For the TvrIndicator, see the attached project which will crash with the exception when the LED Test button dialog is dragged over from 100% to 250% screen (Just not sure if that is your or embarcadro issue - I know it gets passed a negative number).
Have you been able to reproduce? If not, I'll fix it but tell me how I do the build (also be nice to have the debug version available) - once done I can send you a patch file. I don't have problem coding, just new to c++builder/delphi and the build environments. I would like to build for debug, be able to debug, make changed, build that change, then run the main program again.
the exception / negative value may be from the RTL - maybe c++ builder 11.3 you'll see it.. But I'm talking about the other issues with the line height/spinner widths/etc .. How can I rebuild things easily to dig in to it .. using c++ builder 11.3 (I have to use command line compiler which comes with c++builder or do have a delphi community edition installed) .. I'd like to just emulate the installer but create debug version ...
Also for the record: 2 monitors in Win10 x64. Monitor 1 is on the right that has a resolution of 3840x2160 (put it to 250% for testing), Monitor 2 is on the left, primary monitor, resolution is 2560x1600 (100%). The "Multiple Displays" is set to "Extend these displays" and Display Orientation for both is Landscape.
The list when moving from 100% to 250% back to 100%
On the EDIT and SPIN controls:
On the 250% screen for both the edit and spin fields, the first time it opens the width is decent, however the second time you open it up it's way to small.
On the TAdvTreecomboBox, when you open the list (the dropdown list) on the 250% screen, it's HUGE, so huge you can't see the top. It's almost like it double the zoom on both width and height.
I'm not the only one seeing it, the testers in different states see the same thing.
Have you been able to reproduce and working on a fix? The app is pretty much done except for resolving issues with dpi changes and the tms components (and the exception issue which may be Borand's issue - easier to remember how to spell).
