DELPHI AREA Forum

Hi, i am using Windows 10 1607 and Delphi XE Berlin 10.1.

I have compiled the demo :

I have execute it on my computer it is ok, but if i execute the exe on some other computers i have a problem of size, je canvas is smaller.

Best regards

Yannick

Hi,

If i generate a PDF (SYNOPSE) from the PrintPreview the PDF has a good scale and good size.

I have also tested the demo on two server 2012r2, on one it's good, on the other no...

Very Strange !

I use this component since many years and i have never see a problem.

Yannick

This has to do with virtualization of screen resolution windows uses on high res monitors that are all the rage now. This issue is a major issue for Windows users with all the new high res screens in use with code that does not turn off virtualization in settings or the manifest.

I use the unit and am interested in getting the native res (not the visualized setting) and modifying the unit to adjust for this in the page displays. All the other forms work fine with virtualization.

Great component, very well written, thanks!

Hi,

You are right !

The problem was on a Windows 2012r2 on VMware, on others Windows 2012r2 on Hyper V i do not see that.

It's very Strange. Is there a workaround ?

Thany you

Yannick

Still checking if the code can be modified to handle higher dpi without using higher dpi for the whole app. One option would to get the native dpi before the app starts fully and use the native dpi in the PrintPreview to correctly show the pages.

In this case the app will run in virtualized 96 dpi but print preview pages at the native higher res.

Did get some success on this but still needs work.

If you run with dpi aware in Vista to W10 it seems to be fine but with older code you would need to make MAJOR mods in all the forms generally. The dpi in W8.1 and later systems now can change dpi from one monitor to the other as well.

With low cost high res monitors this is more important than just a few years ago.

Any help on this would be great. Would love to keep using this great preview option.

For GetDeviceCaps(ACanvas.Handle, LOGPIXELSX) and for Y substitute the the native real DPI of the target monitor seem to work when writing to the page displayed on screen and not when it is used for actual printing.

It would be nice to do a simple test if ACanvas is a printer.

Could use PrintPreview.DirectPrint to see if printing

Hi guys,

Thanks for your effort in resolving this problem.

FYI, the canvas is a printer's canvas if the State property of the component is psPrinting.

Not sure at this point but it may be easier to make the app DPI aware than to modify TPrintPreview. With DPI aware TPrintPreview does work well and would like to keep using it. Very useful Unit for many kinds of print previews. Seems changes to the unit could make it work with non-DPI aware setting but I'm having trouble with all the changes seemingly need to make it work. May be some easy changes but I don't see it.

Lots of issues with windows new DPI aware changes others are reporting on. Even some of windows own programs are not DPI aware yet. But this is getting to be the new normal with high resolution monitors.

With the new Windows 10.1 Redstone 1 update TPrintPreview works well as a virtulized Windows form except when the QHD laptop screen is running alone (no external monitor) and not at 100% Display Mode Setting. Strange. This is an improvement in Windows management of Hi Res virtulized screens.

Windows is expected to update early next year with 10.1 Redstone 2 which may fix this. The MS Windows managers interviews I have read indicate more work is planed to handle High Res screens that still have some issues, maybe like this strange scaling error.

When there is an issue the rendered content of the pages are about 75% of what it should be including a box showing the margins, similar to those shown in yannick's attachments.

Will keep working on this new issue that will still be a problem for some users as many laptops with Hi Res screens are not used at 100% because the icons and text are way to small to read.

Thanks.

Hi,

I am using TPrintPreview component in my project.
Recently we are experiencing issues with printing/previewing.

Symptoms are similar to those described above (Preview is roughly 25% smaller then it should be).
By testing we found out that if we set Windows DPI scaling back to 100%, everything works fine. Another working solution is to "Disable Display Scaling On High DPI Settings" in Compatibility tab under application Properties.
This is however not satisfactory for our clients, because fonts are way to small to read.

Is there any way to solve this within code?

Thank you very much for any advice or information.

To resolve this issue, all you need is to equip your application with the right manifest to make it DPI aware.

Here is a manifest that works fine with my Delphi 7 compiled codes:

Code: Select all

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
  <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="YOUR COMPANY NAME" type="win32" />
  <description>YOUR APPLICATION DECRIPTION</description>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" />
    </dependentAssembly>
  </dependency>
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>

For example, to fix the DPI issue of the PrintPreview's general demo, modify the main.pas file as follow and copy DPI_Aware_Manifest.res in the source code folder.

Using the manifest may be a good suggestion for some Delphi Applications. But like some comments above your app will have very small fonts and icons, for example on a QHD laptop. Currently with standard virtualization there are no issues at all at 100% display setting but issues with 150 or 200% display setting without an external monitor. With external monitor works well. Windows inconsistent display virtualization in Windows 10.1 Redstone 1 update. To use DPI Aware setting on a high DPI system you will need to change the scaling of the form or forms to make the form usable and, even re-scale on moving forms to another monitor with a different DPI while in use. Not needed with virtualization.

For the near future it would be great to just keep the standard virtualization with 96 dpi and have just the preview page scaled. All my many forms work well in this mode with just changes needed in the preview form.
Thanks again.

See recent post on this forum on a potential simple change to TPrintPreviewto handle high dpi.

Thank you very much VPC16 for the fix.

I just released an update for the component by using your scaling solution.
The mouse wheel issue is also fixed in this update.