Print out and Screen Zoom Faktor 4

[Christoph_B]

Hi all,
I have a problem with the screen scale value in Windows and the printer output scale. Some of my users are using a screen scale of 125%. In this case, the output of a report of an Foxpro applicastion is also scaled to 125% and the output doesn't fit to the paper size.
Is there an option to create the print out independent of this screen scale factor?

KR
Christoph

 

[Premal Vala]

Hi Chris,

I faced this issue but was able to solve by windows High DPI settings. You can set "High DPI Scaling Override" feature. Right click on your program icon and click properties and then select "Change High DPI Settings" and tick "Override high DPI scaling behavior. Scaling performed by Application.

See below screenshot. This should resolve your problem.

 

[Christoph_B]

Hi Premal,

thx a lot. Super.

KR Christ

 

[Chris Miller]

We discussed dpi awareness a lot in recent weeks and months and the problem I have with this exe property setting is that it doesn't copy when you copy the exe elsewhere, which makes me think it also won't get into a setup you do for an EXE with that property.

MS mentions dpiawareness can be put into an exe manifest and you can easily embed a manifest differing from the standard VFP executable manifest by creating a projectname.manifest file in the project directory and do a build. See https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests?#dpiAwareness

There's deeper discussion about this at an older thread https://www.tek-tips.com/threads/dpi-awareness-manager-questions.1821313/

I'd always recommend using atlopes dpiawareness manager at https://github.com/atlopes/DPIAwareManager.
And, yes, this does not only affect screen display, that also affects printing.

 

[Christoph_B]

Hi Chriss,

It seems, it runs well with the settings in the Windows resolution...
But I would like to test also your proposal. Do you have a code example with the dpi awareness manager for using a report?

Thx in advance
Christoph

 

[tomk3]

Hello,

you may also try this at the start of your program :

DECLARE INTEGER SetProcessDPIAware in WIN32API
=SetProcessDPIAware()

If you use a loader.exe to load another exe, it should be in both

 

[Chris Miller]

Christoph, the code example is on the github readme, isn't it?

After you add the dpiawaremanager.prg you just create the DPI manager like this:

PUBLIC DPI AS DPIAwareManager

m.DPI = CREATEOBJECT("DPIAwareManager")

On top of that, and I though the init of the class does it, you should do what Tom suggests.

 

[Christoph_B]

Hi Chriss, hi Tom
I undid the changes in the screen resolution and did the following changes in my app (main.prg):

PUBLIC DPI AS DPIAwareManager
...

SET PROCEDURE TO C:\projekte\PTKBLOKA\dpiawaremanager additive
DECLARE INTEGER SetProcessDPIAware in WIN32API
=SetProcessDPIAware()
m.DPI = CREATEOBJECT("DPIAwareManager")


All the reports are created in another form.
All the printouts and the PDF's are looking perfect


Is that really all I have to do?

BR
Christoph

 

[Chris Miller]

Yes, for reports the dpi aware manager does not do anything more, but no, you will have to follow the instructions on GitHub to also make all your forms work dpi aware, that plays a role when Windows is configured to scale fonts and when you therefore need to resize VFP controls and adapt font sizes, etc. and even more so, if you use ActiveX controls that don't adapt on their own.

What's done with the SetProcessDPIAware call is telling Windows to not interfere with font and image sizes, which in case of reports being rendered in gdi bitmaps obviously makes a large difference. The automatic intervention of Windows obviously does the opposite of what it should in the way VFP addresses GDI+, at least, as it renders text even larger than just the Windows scaling factor does.

It's just oppinion, but I already seaid not long ago, Windows intervention may be okay in many cases, we only ever hear about the cases it doesn't work well, but all in all telling Windows your application cares for how large things are rendered itself is taking away unwanted changes, but also puts you into the responsibility to use larger fonts to not look unreadably small on big high densitiy displays.

I think VFPs report render engine always was and is okay, as printer DPIs differ from display DPIs and were already higher than the old 96dpi even in the 90s. So especially reports seem just to be victim of Windows interventions in applications that don't tell they are dpi aware.

We had lengthier discussions already in the forum, if you jsut search for dpi awareness, you'll find that.

 

[tomk3]

Hi,

DECLARE INTEGER SetProcessDPIAware in WIN32API
=SetProcessDPIAware()
should be enough. I do not use (yet) the DPI manager which offers much more, especially in multimonitor systems with different scaling.

For resizing controls I suggest to look for Markus' mwresize5.1 or 5.3. One line of code is enough. I preferit to anchor.
You may easily add some code to save settings per form and per user.

 

[Chris Miller]

The description of SetProcessDPIAware

Has the note

It is recommended that you set the process-default DPI awareness via application manifest, not an API call.

So there's more to it.

I think you can't mix Markus Winhards mwresize with the dpiawaremanager, but I haven't tried that. Overall, there's already a lot of more information in the readme text of https://github.com/atlopes/DPIAwareManager, just go there and please read it, and you would have less questions.

The code of the dpiawaremanager used for forms will scale (resize) controls and allow to use anchoring anyway, it does scale in a way the anchoring doesn't have recursive side effects but still respects both forms and controls with and without anchoring, determines the scale factor necessary for both original vs. current size and dpi change in comparison with norm and the scaling factor configured in Windows by making use of the WindowsAPI functions that can tell that per form/system/monitor, that's more than any previous form resizer does. I think you'll be best off not mixing the dpiawaremanager with any resizer whatsoever, but could work if first using the resizing and then the dpimanager manage method in that order.

I suggest to look for Markus' mwresize5.1 or 5.3. One line of code is enough

That's the same for dpiawaremanager, plus you can get away with one line of code in your form manager starting forms, no code in any form or form class on top of that, so that takes even less effort than integrating mwresize or any other resizer.

 

[Christoph_B]

Thanks a lot for your explanations. I will go deeper in this stuff and I will adapt my app where it is needed.
For the time beeing, I'm really happy for the tips that the print out are not longer cut.

KR Christoph