TPrintPreview problem

Please post bug reports, feature requests, or any question regarding the DELPHI AREA products here.

TPrintPreview problem

Postby yannick » August 24th, 2016, 8:00 pm

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
Attachments
mycomputer.png
mycomputer.png (92.19 KiB) Viewed 2177 times
othercomputer.png
othercomputer.png (212.82 KiB) Viewed 2177 times
yannick
Active Member
Active Member
 
Posts: 15
Joined: May 20th, 2006, 2:03 pm

Re: TPrintPreview problem

Postby yannick » August 25th, 2016, 1:55 pm

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
yannick
Active Member
Active Member
 
Posts: 15
Joined: May 20th, 2006, 2:03 pm

Re: TPrintPreview problem

Postby VPC16 » August 30th, 2016, 2:50 pm

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!
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby yannick » September 9th, 2016, 6:37 am

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
yannick
Active Member
Active Member
 
Posts: 15
Joined: May 20th, 2006, 2:03 pm

Re: TPrintPreview problem

Postby VPC16 » September 13th, 2016, 8:42 pm

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.
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby VPC16 » September 20th, 2016, 2:40 pm

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.
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby VPC16 » September 20th, 2016, 3:31 pm

Could use PrintPreview.DirectPrint to see if printing
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby Kambiz » September 21st, 2016, 10:59 am

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.
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: TPrintPreview problem

Postby VPC16 » September 29th, 2016, 3:32 pm

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.
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby VPC16 » October 27th, 2016, 6:05 pm

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.
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm

Re: TPrintPreview problem

Postby Alatyr » October 31st, 2016, 12:49 pm

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.
Alatyr
Member
Member
 
Posts: 1
Joined: October 31st, 2016, 12:41 pm

Re: TPrintPreview problem

Postby Kambiz » November 6th, 2016, 9:46 am

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.

Demo.General.Main.png
Changes in main.pas
Demo.General.Main.png (21.33 KiB) Viewed 1716 times
Attachments
DPI_Aware_Manifest.res
Compiled manifest resource
(816 Bytes) Downloaded 29 times
Kambiz
User avatar
Kambiz
Administrator
Administrator
 
Posts: 2408
Joined: March 7th, 2003, 7:10 pm

Re: TPrintPreview problem

Postby VPC16 » November 8th, 2016, 6:31 pm

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.
VPC16
Active Member
Active Member
 
Posts: 9
Joined: August 30th, 2016, 2:26 pm


Return to DELPHI AREA Products

Who is online

Users browsing this forum: No registered users and 2 guests