FoxChart report problem with 4K screen

[Gerrit Broekhuis]

Hi,

I'm using FoxCharts (latest version) for showing graphs on forms and in a report. So far the 2014 document "Add Beautiful Charts to Your Applications Using FoxCharts" by Doug Hennig has been a great help.

However, in my test application I have a problem with the report. I created a canvas on the form for the graph with 700 x 300 pixels. The image on the report is fine, see attachment.
For the report I use the EMF, created with:

private oChart
oChart = Thisform.oChart.DrawReport()

In the report I added the graph as shown in the attachment. The picture is again 700 x 300 pixels on the report. I tried all scaling possibilities, but with "scale contents - retain shape" and "scale contents - fill the frame" the image is much smaller than expected (there is a lot of grey below and on the right of the chart). If I use "clip contents" instead the image is way too big and only a fragment is shown.

This problem has something to do with the native screen resolution. My development W10 laptop has a 4K screen and that's where I have this problem. On my older W7 laptop with a Full-HD screen the report shows just fine (using the "scale contents - retain shape" setting). Apparently the EMF file is depending on the screen resolution. My VFP application runs with a Full-HD resolution (not 4K, everything becomes too small for my eyes).

So I know that the presense of a 4K screen creates the problem, but how to solve this?

Regards, Gerrit

 

[Mike Lewis]

Gerrit,

This sounds very similar to a problem I had a couple of years ago. Like you, it worked OK on my main desktop machine, but not on a laptop under Windows 10.

In my case, the user with the laptop had increased their font scaling to 150%. When I suggested they set it back to 100%, the problem went away (this was at a resolution of 1360 x 768).

Does that help at all?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Gerrit Broekhuis]

Hi Mike,

I just checked the display information. The native screen is 3840 x 2160 pixels. For my applications I run with 200% scaling, so I effectively use 1920 x 1080 (Full HD).
I just ran my application with no scaling at all. Everything becomes very small, but I was able to run the program. And with this 100% scaling the chart is OK.

Of course I can never run my application with the 4K resolution without a lot of work (make it DPI-aware).

So perhaps I need something to cut off the unnecessary grey parts of my EMF graphic in memory? I have absolutely no idea how to do that...

Regards, Gerrit

 

[Chris Miller]

The chart should just be made with double width and height.

When you turn on 200% scaling, you don't reduce the resolution to HD, you still are 3820x2160 pixels. You just have a higher dpi.
A report in itself has the dpi of the printer, not the screen, but the screen dpi has influence on the preview.
Do you use foxypreviewer, becasue they made that dpi aware.



Chriss

 

[Scott24x7]

Have you tried adding this to your early startup code:

DECLARE INTEGER SetProcessDPIAware IN WIN32API
SetProcessDPIAware()

Best Regards,
Scott
MSc ISM, MIET, MASHRAE, CDCAP, CDCP, CDCS, CDCE, CTDC, CTIA, ATS

"I try to be nice, but sometimes my mouth doesn't cooperate.

 

[Gerrit Broekhuis]

Hi,

I will work again on this next week.

Regards, Gerrit

 

[showiedash]

Here is another link that may help - there are some issues with the rendermode on some machines. Looks like changing .rendermode = 1 may be an option. It just worked for me on some Win10 machines that wouldn't display:

https://www.foxite.com/archives/foxchart-win10-fix-0000432809.htm

 

[Gerrit Broekhuis]

Hi showiedash,

I was able to solve this problem by saving the chart to a file and using this file in the report.
Working this way is free of scaling issues.

Regards, Gerrit

 

[Chris Miller]

I'm reminded when apple introduced retina displays with higher DPI they acted towards apps by scaling images up. The system reports a HD resolution instead UHD, for example, so the only benefit about the high DPI was with fonts and SVG rendering sharper.

I'm unsure how Windows exactly handles dpi when your app does not say it's dpi aware. I just experience output on screen being blurry, not wrong sized. But I'm pretty sure Scott is on the right track with dpi awareness making a difference. And I remember they made a fix in foxypreviewer to handle this correctly. I wonder a bit how it all comes together, as printer dpi and display dpi were already different back in the 90s when displays still were mainly 96dpi and printers started to have 150, 300, or 600 dpi, albeit only in black and white. So preview and print have a long history of being in different dpi and it's not just a problem of the VFP 9 report engine.

I see that your problem already starts on the preview, that is for the display, same DPI, actually. So all that seems irrelevant, yet the preview obviously thinks it has to lower the size of the image.

I guess using an image solves the problem as that problem of dpi mismatch has already been solved for bitmap images. But I think it's still worth trying to get the preview and printing rendering correctly to have best output quality. It won't change the look of such a bar chart much, but the text, especially the small year-month labels could come out much cleaner when you get to the bottom of the problem and can fix it.

The simplest fix in your situation would be generating the bmp with higher resolution than necessary, so it may be sized down in both the preview and printing pass, but to the right respective area.

Chriss

 

[vernpace]

Here is a great article on GDI Scaling. Scroll down to the section: GDI Scaling for Developers. GDI Scaling was implemented in Windows 10 version 1703 (Creators Update). There is an example manifest in the section: Updating your GDI app to use GDI Scaling

https://blogs.windows.com/windowsde...I Scaling scales up the,app with a 20pt font.