Winforms Reports Shink when Scaling is on

6 posts, 0 answers
  1. Luke
    Luke avatar
    11 posts
    Member since:
    Dec 2013

    Posted 08 May 2018 Link to this post

    We're using Telerik Winforms (2018.1.220.40) and Telerik Reporting (12.0.18.416). When a computer with Windows High DPI Scaling set to greater then 100% prints a report, the report is tiny and shrunken in the corner of the page.

    Due to many of our users using Surface Tablets, this issue is a must fix. Please let us know how to resolve it. I can reproduce the issue with a sample project that with an incredibly simple repor, so it's nothing in our code.

  2. Silviya
    Admin
    Silviya avatar
    413 posts

    Posted 09 May 2018 Link to this post

    Hello Luke,

    When using Windows Forms ReportViewer on a machine with DPI scale factor higher than 96 (100%), Windows will stretch the application bitmap to the expected physical size.
    This makes the report viewer and the report content blurry. However, when you are trying to print the report, the Windows Forms viewer always bases the layout calculation on 96 DPI and it will print the report as it will be previewed in 96 DPI. This is because the application in which you are using the Windows Forms Report Viewer is not declared as DPI aware.

    By default WinForms applications are declared as DPI Unaware. As such, the report viewer and the physical size of report cannot automatically handle DPI scaling and, as a result, will render blurry or be sized incorrectly in many common usage scenarios. So, when printing the report, the application doesn't respond (don't know about the machine's changed settings) to the changed DPI and scale it incorrectly.

    The recommended approach is setting dpiAware element in your application to avoid further scaling, visual or interaction issues. For example:
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
      <asmv3:application>
        <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
          <dpiAware>True</dpiAware>
        </asmv3:windowsSettings>
      </asmv3:application>
    </assembly>

    You might also check our demos located in product installation path, i.e. C:\Program Files (x86)\Progress\Telerik Reporting <VERSION>\Examples\CSharp|VB\WinFormsDemo. The 
    dpiAware.manifest file is placed at the root of the application.

    Regards,
    Silviya
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  3. Luke
    Luke avatar
    11 posts
    Member since:
    Dec 2013

    Posted 09 May 2018 Link to this post

    The dpiAware element didn't help as posted. However, when I copied the manifest out of the WinFormsDemo you mentioned, that appears to work. The difference appears to be "<dpiAware>True/PM</dpiAware>" instead of "<dpiAware>True</dpiAware>"

    Thanks for your help!
  4. Silviya
    Admin
    Silviya avatar
    413 posts

    Posted 09 May 2018 Link to this post

    Hello Luke,

    As far as I can tell, true vs true/pm should make no difference whatsoever on a system with only one display. In case you have more than one monitor, setting true/pm means that the current process is per-monitor dpi aware.

    For more information, check Application Manifests MSDN article and more concrete dpiAware section.

    Regards,
    Silviya
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
  5. Luke
    Luke avatar
    11 posts
    Member since:
    Dec 2013

    Posted 09 May 2018 Link to this post

    Unfortunately, while the solution provided does solve the printing problem, it has the side effect of making the entire application too small for our users. 

     

    Why would the *display* DPI setting affect what's printed in any way? Can this behavior be disabled? We want the default windows behavior of "blowing up" our application by 200%, without it affecting printed reports.

  6. Silviya
    Admin
    Silviya avatar
    413 posts

    Posted 10 May 2018 Link to this post

    Hello Luke,

    WinForms ReportViewer uses the Image Rendering that takes information about the DPI settings from the application and the machine. When DPI is higher than 96 (for example 200%) and the application is declared as DPI Unaware, the report viewer and the physical size of report do not automatically handle DPI scaling and, as a result, will render blurry or be sized incorrectly in many common usage scenarios. So, when printing the report, the application don’t respond (don't know about the machine's changed settings) to the changed DPI and scale it incorrectly.

    For more information, please check High DPI desktop application development on Windows MSDN article.

    As WinForms applications are not DPI aware by default, we strongly recommend to set dpiAware element in your application to avoid further scaling, visual or interaction issues.

    And as of the scaling of the report viewer as 100%, you can easily build custom UI for the toolbar and work with the rendered report in the viewer. In this case, you can use the Windows Forms ReportViewer class.

    Regards,
    Silviya
    Progress Telerik
    Do you want to have your say when we set our development plans? Do you want to know when a feature you care about is added or when a bug fixed? Explore the Telerik Feedback Portal and vote to affect the priority of the items
Back to Top