VFP IDE on Full HD laptop

[JackTheC]

Laptop Full HD (1920x1080) and Window 10 or 11 scales to 125%.
So VFP(6) IDE is 1536x864 virtual pixels, still 1920x1080 hardware pixels. Resulting in blurry characters in IDE, but I can live with that.

Working on a program/form that I want to scale itself. Like 125% too or 140%, whatever.
Windows scale is set to default 100% by issuing commands:
DECLARE INTEGER SetProcessDPIAware IN WIN32API
SetProcessDPIAware()

If I would do that while a form is already visible at 125%, the form is immediately resized to 100%. IRL I issue these commands before any form is visible.

After test run of program within VFP's IDE and returning to IDE, scale 100% is still active so the characters in the IDE are very small and hard to read.
Only way to return to 125% in the IDE is to quit VFP and restart VFP.

I am looking for a (set of) commands to undo SetProcessDPIAware() that I can place at the end of my program so the IDE is "normal" and I don't have to quit after each test run. Any ideas?

I guess every programmer working on a Full HD laptop, making apps High DPI aware has the same problem. How do you solve this?

 

[Mike Lewis]

Jack,

You could try calling [tt]SetProcessDpiAwareness(0)[/tt], passing a value of zero. (Note that SetProcessDPIAware() and SetProcessDPIAwareness() are two different functions.) According to the Microsoft docs, doing this will make the app ...

DPI unaware. This app does not scale for DPI changes and is always assumed to have a scale factor of 100% (96 DPI). It will be automatically scaled by the system on any other DPI setting.

I'm not sure about this. Although I always call SetProcessDPIAware() at the start of my apps, I've never felt the need to call SetProcessDPIAwareness() at the end, but it would be worth a try.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

This explains the issues you had in your earlier thread, doesn't it?

Resulting in blurry characters in IDE, but I can live with that.

I couldn't, but that's your choice, of course.

You could make all font sizes larger in the IDE, so you get sharp fonts and graphics. Shapes lines, for example also become blurry in the OS managed rescaling mode, so it's really ugly aside from the wrong virtual dimensions reported by size-related properties.

On my development PC Or laptop I'll never set systemwide scale factor to anything higher than 100%. You can change things in themes in other ways to make things better readable, large icons is one example. Sharp text is better readable to me even when it's smaller than large text. And I wear reading glasses. A larger secondary display would obviously also help.

I can't contribute something else to Mikes answer. I think you won't get access, as far as the documentation about SetProcessDPIAware() tells, its equivalent to calling SetProcessDpiAwarenessContext(DPI_AWARENESS_CONTEXT_SYSTEM_AWARE) and DPI_AWARENESS_CONTEXT_SYSTEM_AWARE is described as: System DPI aware. This window does not scale for DPI changes. [highlight #FCE94F]It will query for the DPI once and use that value for the lifetime of the process[/highlight]. If the DPI changes, the process will not adjust to the new DPI value. It will be automatically scaled up or down by the system when the DPI changes from the system value.

From that I read it's a once only change you're not able to undo, as the setting is done "for the lifetime of the process".

Edit: The following only applies to VFP9 with task pane and a reference to gotdotnet.com, so forget about it, I just leave it in as it's useful for VFP9 users...

I know the start of VFP can be slow, if the task pane is active. Solution: Turn it off. Another thing causing a slowdown is the non-existence of the website gotdotnet.com. You should remove one thing from foxtasks, as described here:

https://social.msdn.microsoft.com/F...t-remember-defaults?forum=visualfoxprogeneral

*-- Open the TaskPane content table
USE ADDBS(justpath(_foxtask))+'TaskPane\PaneContent'

*-- Move problematic web links to OptionPage memo
REPLACE OptionPage WITH Data FOR DatSrc = 'U' AND 'gotdotnet.com' $ LOWER(Data)
REPLACE Data WITH '' FOR DatSrc = 'U' AND 'gotdotnet.com' $ LOWER(Data)

USE

Now VFP should start fast even with task pane on and if you have VFP installed on an SSD drive that start is split seconds.

...Edit 2:the following recommendation is working for any VFP version:

Even better when using a RAM disk. See my post in thread184-1812450 from time 22:08.

Chriss

 

[Chris Miller]

Well, and to state the obvvious: I find it most easy and comfortable to restart VFP to get it back to all defaults.

If you work with frameworks like VFX that load at Foxpro start, that slows things down a bit again, but not that much. Besides for me it's a sign of a bad design of a framework if it needs long initialization. You don't get around it, if some projects are made with such frameworks and the IDE designtime functionalities are compensating for the wait, surely.

Chriss

 

[JackTheC]

Thanks for the answers Mike and Chris. I haven't studied Chris's answer in deep yet.

But I have tested with ....Aware, ....Awareness and ....AwarenessContext API calls.
In fact they all do the same in setting DPI Aware:
Aware with no parameters, Awareness with 1 as parameter and AwarenessContext with -2 as parameter.
But as Chis stated they can all run (or set) once. And you cannot mix these commands.
No undo setting possible because that would mean a second run.

As I mentioned you can scale a running and visible form back to 100% but for now, not back to the previous Windows scale (125%). And that is strange.

 

[Chris Miller]

And that is strange.

Yes, but dpi awareness is doing my head in anyway. The documentation of SetProcessDPIAware has the note:

It is recommended that you set the process-default DPI awareness via application manifest, not an API call. See Setting the default DPI awareness for a process for more information. Setting the process-default DPI awareness via API call can lead to unexpected application behavior.

So file it under "unexpected application behavior". VFP9 has an embedded XML manifest, that didn't exist in VFP6. You should be able to define a manifest and save it into HOME() as vfp6.exe.manifest and specify the dpiawareness and other things in there, not using the API call. Though I think the warning of this note does not apply to VFP itself, as in itself VFP isn't dpi aware anyway. The problem is, that the OS is doing a bad job regarding the blurring of graphics due to blowing it up. Scaling graphics up leads to blur with any method, and VFP is only bitmap oriented, not vector graphics. So even simple 1 pixel horizontal or vertical lines become blurry lines. It's simply bad, no matter how you do it.

You can have ActiveX controls which are dpi aware and will scale correctly keeping their sharpness in captions/fonts. It would be good if it would be documented anywhere how you take this control yourself. Anyway, leaving it to the OS to scale things up is never going well regarding sharp graphics and text, even though text indeed is scalable graphics with so-called bezier curves and then there is ClearType on top of that. I think the problem is that low font sizes are not using this vector graphics mode but are stored as bitmap representation of the fonts and that gets scaled up blurry.

All in all pretending to be a dpi aware process leaves the OS out of what's displayed. This leads to the small fonts in HD displays by default, but as already said, you have control about almost any font sizes which are relevant, especially in the command window and any edit window, memmo popup windows etc. And of course in all VFP forms and controls.





Chriss