Hi Antonio,
It's worth the work. The tricky is all the stuff we don't have control off like Sysmenu and Captions, and to fiddle with all the menu declarations that simply are non class.
Different windows on different monitors are a pain. Try moving / scaling / splitting. Just move the debugger outside is a pain.
Report Preview (and throuh that output at all) is pretty well with Chen, Report Design as well. For now I develop in VFPA and ship in VFP, my main customer uses no High DPI, but I'm aware of it.
VFPA (or it's VFP part) scales well enough, but for the moving etc. it sets the focus on windows main screen. So any other is odd.
Maybe you try to read Chens documentation yourself. I commit that the layer of English between myself and Chen is a layer to much to me.
http://www.baiyujia.com/vfpdocuments/default.asphttp://www.baiyujia.com/vfpdocuments/f_vfp9fix127.asphttp://www.baiyujia.com/vfpdocuments/f_vfp9fix128.aspLutz
>Thank you, Lutz.
>
>I understand there's a bumpy road ahead, but I think that we can track that particular change of condition (moving the application to a different monitor). What the application must do in response to that, well, that's the question. Even trickier, I think, is to control different top windows that may be displaying in different monitors.
>
>Regarding VFPA: does it improve on the inclusion of a DPI-aware clause in a regular VFPSP2 application manifest?
>
Words are given to man to enable him to conceal his true feelings.
Charles Maurice de Talleyrand-Périgord
Weeks of programming can save you hours of planning.
OffThere is no place like [::1]