Report Form print sizing problem

[TinyNinja]

Hey community,

I need help with VFP Report Form page sizing.

Why is my report being cut off? I have tried everything to get it to print out the full 8in proper letter size.

This is the look of my form, I am trying to place a picture into every report that gets printed. The pictures below I am just running the preview option in the project area of the program. I don't have it fully running in the program live but I'm getting this same problem regardless of which way I run the report. I have set the printer to a real printer vs a PDF creator and haven't seen anything different happen.

Set ReportBehavior 80 - allows the whole report to be created but no picture.

Set ReportBehavior 90 - cuts the print out in half and I don't a chance to see the picture. The picture might be present but I have no clue.

Current settings

The code I'm using in the code.

 

[mjcmkrsr]

Hi,

You may want to click "Override High DPI Scaling behavior ... " and start VFP with this setting checked - see my post above (9 AUG 2024 - 8:57)

hth

MarK

 

[TinyNinja]

Hey mjcmkrsr, I have made the change but I'm keeping it at the system options since when I click the application it shrinks down to a super small size since I'm using a 4k monitor. Everything matches up correctly when I run the exe alone but doesn't match while in the IDE which I'm ok with.

 

[Chris Miller]

You will always have this problem on any Windows with scaling set to anything other than 100%.

From that perspective the FoxyPreviwer.App is a better reporting app than the original ReportPreview.App and ReportOutput.App and it indeed covers both functionalities, as it would of course be unhelpful to only change the preview and not the final output. To be clear, FoxyPreviewer could also replace the original VFP ReportPreview.App and ReportOutput.App files.

Xinjie pointed to the VFPX page that has the latest original VFP versions of them, and MarK pointed out where they go. Well, that's all part of the SP2 update of VFP9, too, and if you upgrade the reporting apps, you should upgrade your whole VFP9 IDE to the latest version SP2 and then Hotfix 3.

Anyway, if you provide an EXE and want it to support REPORTBEHVIOR 90, then you also have to provide all three apps (well, ReportBuilder.app only when your application actually allows to modify a report). And the FoxyPreviwer.App is a replacement for the ReportPreview.App and ReportOutput.App

What I wouldn't do, even when it turns out the dpi scaling problem can't be overcome otherwise is replace the VFP reporting apps with foxypreviewer already in the IDE environment. FoxyPreviewer makes it so easy as just DO FoxyPreviewer.app to change from the native VFP apps to FoxyaPreviewer, that it's worth - in my opinion - to keep the orignals in place for cases you still use them in an application in production. Of course, you still want to be able to test bugfixes with that apps in place.

What's also good to know is that without the apps, the VFP9r.dll still contains the 70 reportbehavior reportengine and is acting as a fallback to 90 behavior, if the apps are not available to the runtime, also see _reportoutput, _reportpreview and _reportbuilder system variables explained in the VFP help.

The thing about dpiawareness is not to fix all scaling problems, but to keep the OS from interfering with scaling and handling it yourself, setting an application to be dpiaware tells "I am aware of the need to scale up fonts and images myself". But then you still need to do exactly that yopurself. Since FoxyPreviewer is not just defining a new reportpreview window but a whole GDI+ based rendering of reports, it can do for reports what atlopes DPIAware Manager does for forms.

From what püeople told about their SetProcessDPIAware experiences it seems diffferent Winddows versions, maybe even different builds act differently. In my experience all text (fonts) are immediately crisper when you use SetProcessDPIAware or the EXE property setting shown by MarK or the manifest declaration as recommended as best practice. The different experiences may also come from the timinig of that API function call. At best Windows knows from the EXE manifest even before the process really is running. Also the documentation of the API function says it the process-default DPI awareness to system-DPI awareness, so it can differ what's the system setting for DPI awareness, you can configure some behavior there and what can be configured differs with Windows versions, I think.

The usual result of SetProcessDPIAware is that font scaling doesn't happen, for example, so your forms will become small on a higher resolution display. For that reason you should have forms that can adapt to higher reslutions anyway. If you do that you make any influences from Windows unnecessary and that's the core of stating your application is dpi aware. You're aware that on displays with higher dpi you need to take care for forms and especially all text on them doesn't get so tiny even young poeple would need magnifiers or reading aids to be able to use them.

The report problem originates in several scaling issues, I think, not just one. I'm not sure, but I think VFP has the hardcoded assumption that screens (so the preview phase of a report) always have 96dpi displays, so a 1080 display has an actual phsyical width of 11.25", which actually is close to that, really. A 14" (diagonal) 4:3 display has 11.44" width. And the typical 96dpi is from that era of 4:3 displays. If both dpi is higher and scaling factor is set high to comensate the smaller size of the same number of pixels, the rendering engine assuming 96dpi will therefore assume a much larger physical width and sclaing of font by windows does not counteract but even magnifies the problem, so that you get too large rendered fonts and only see half of the preview. That's why that happens, simplified. The printer driver will also weigh in later with a dpi of the printer, but that was always handled even before displays with higher resolutions and what's more important higher densities of pixels were a thing, because printers even had 300/600/1200 dpi in the 90s already and today even more.




Chriss

 

[TinyNinja]

Hey Chris,
You make a lot of sense and point out many great things that I wasn't fully thinking of. I have changed my code around to use FoxyPreviwer again to avoid scaling problems going forward. I have Visual FoxPro 09.00.0000.7423 installed on my machine. I don't remember the VFP9 ReportingApp ever being apart of the list of steps I normally take when I install VFP onto a new machine. I updated all the other files for the Hotfix 3.

I agree I wasn't planning on removing the native vfp reporting apps. I believe calling FoxyPreviwer being the smart option. Once I finish the Form and some coding then I will go back and try putting in the Form DPI code. I did notice the 96dpi settings in the properties of VFP and that makes sense on why scaling up to the bigger monitors is such a problem.

 

[Chris Miller]

Hello TinyNinja,

09.00.0000.7423
That's the version number you get from upgrading to Hotfix3, so you already did that.

If you move from PC to PC, it's not enough to copy the installation directory. Some files, including runtimes and reporting apps are in
C:\Program Files (x86)\Common Files\Microsoft Shared\VFP

Even if you didn't install VFP9.exe into C:\Program Files (x86)\ that's where those files are:
VFP9rrus.dll
VFP9t.dll
foxhhelp9.exe
foxhhelpps9.dll
gdiplus.dll
ReportBuilder.app
ReportOutput.app
ReportPreview.app
VFP9r.dll
VFP9rchs.dll
VFP9rcht.dll
VFP9rcsy.dll
VFP9rdeu.dll
VFP9renu.dll
VFP9resn.dll
VFP9rfra.dll
VFP9rkor.dll

Well, and report apps are also directly in HOME(), which is where system variables like _reportpreview point at.

The hotfix readme tells you where to copy which files, so either you did (at least with the vfp9.exe) or you thought readme is optional or you thought copying vfp9.exe is enough.

Even copy over all this, what a new computer lacks is some registry entries, MSXML4, MSXML3, some common controls also some used in VFP tools of the IDE etc. You're bettrer off with
1. Installing VFP9 (no service pack) to a new computer
2. Updating with SP2
3. Updating with Hotfix3

There are other recommendations in the web, but if you want to get 1:1 to the original state that's the way to go and all else is leaving you with some unfnished things. like help (F1) not working.
To get back some settings you also copy over your own version of foxuser.dbf, which is at Sys(2005) - usually in your user profile. Well, on your old PC, not on your new one, there'll be a new foxuser.dbf created, if you didn't copy it, but then that's it with some settings. Nothing absolutely life shattering, so you may not go back, but that's the least you're missing, more damaging is missing MSXML3,4 and some common controls. You can DO VFPCLEAN.APP, but that also won't fix installation of MSXML3/4. And it matters for some VFP language functions and classes to work at all.

There's at least one more directory containinng merge modules for installshield (express) that's also mentioned in files with MSM extension and there's not only one for the VFP runtime, there's one for the C++ runtime VFP9 needs and for the help system (chm). They are not essential for the IDE to work, they could be interesting to make installers based on systems that do specifically support those merge modules, it's not that popular, though, even the opposite, Inno setup is popular because you can work directly with the DLL files and not merge modules.

The issues you had with the report are merely by Windows scaling set to anything else but 100%, that's not fixed by the original VFP reporting apps, that's not fixed by MSXML or common controls, the solution to that is in the FoxyPreviwer reporting engine, but you still lack some things you didn't copy over from the old computer as they can't just be copied over and are scattered in several places including registry, system directories and so the shortcuts don't really work. Never had, never will.

Chriss

 

[Dan Olsson]

If you move from PC to PC, it's not enough to copy the installation directory. Some files, including runtimes and reporting apps are in
C:\Program Files (x86)\Common Files\Microsoft Shared\VFP

Even if you didn't install VFP9.exe into C:\Program Files (x86)\ that's where those files are:

Well that's only true if you made a default install, right? I have mine in D:\Program\VFP9, so I can easily move the entire directory to another computer.

 

[Chris Miller]

Files not in Home() are still not in HOME(). And ActiveX controls (the MS common controls) which are not part of Windows anymore (or even Office), won't come over, either.
The help file is not registered in VFPs settings and there are more things astray.

The only thing that's easier when HOME() not within Program Files is that you can easily replace files, work on DBFs, etc. Some IDE tools only create indexes on already present DBF files, when you first use them. Or create FXPS when first running a PRG. Installing in Program Files this results in CDX and FXP files stored separately within a profiles VirtualStore folder due to file redirection.

But in short: You only get to the same state of an installation on a new computer with an installation.

Chriss

 

[mjcmkrsr]

Hi,

I have mine in D:\Program\VFP9, so I can easily move the entire directory to another computer.

Did you try it? Is VFP fully working then?

Please note that a full VFP installation writes files into the following folders (at least):

[ul]
[li]Home() and its subfolders[/li]
[li]Program Files(x86)\Common Files\Merge Modules[/li]
[li]Program Files(x86)\Common Files\Microsoft Shared\VFP[/li]
[li]Program Files(x86)\Common Files\System\Ole DB[/li]
[/ul]

hth

MarK

 

[Chris Miller]

Yes, plus it installs MS Commmon Controls and those will go into System32 or SysWow64, nowadays, and also are not working if you just copy them. Plus MSXML3 and 4 and it doesn't matter that Windows10/11 has newer MSXML versions, XMLTOCURSOR explicitly uses MSXML3, XMLAdapter, XMLTable, and more such XML classes use MSXML4, the versions they use are hardcoded in them.

And I'm sure if you try to start the Task Pane you'll get an error by the Web Browser control missing. It wasn't always a problem, as older Windows versions still also had that and Common Controls, but that's not the case anymore, and you won't get doawnloads of deprecated MSXML versions.


Chriss

 

[EinTerraner]

Why is my report being cut off?

As i see. You're using MS-PrintToPDF" and it's a Pain in my aft deck.
I Use PDFCreator from PdefForge and its even more usefull... see code

** create PDF-name like "INVNO-66012-20240801.PDF"
Lc_PdfName = "INVNO-"+TRANSFORM(InvNumber)+"-"+DTOS(InvDate)
USE (FORCEEXT(<Your_ReportFile>,"frx")) ALIAS T1 IN 0
SELECT T1
SET SAFETY OFF
COPY TO (Lc_PdfName) FOR .t.
SET SAFETY ON
USE IN T1

SET PRINTER TO (<YourUsedPDFcreatorPrinter>)
SELECT <YourPreparedInvoiceTable>
GO TOP IN <YourPreparedInvoiceTable>
REPORT FORM (Lc_PdfName) TO PRINTER [PROMPT]

just replace the "<>" as you need

with PDFcreator you can make autosave and it will create the PDF-File like shown in code above
I Use an older version of PDF-creator because it uses INI-Files and they are easier to reinstall in case of total computer crash

 

[Chriss Miller]

Well, I think you established alöready for yourself that only the foxypreviewer report engine (preview) is rendering a report correctly when Windows text scaling is >100%.
The VFP9 report egine, no matter if from the orignal VFP, SP1 or 2 or the latest hotfix, all versions of that don't take into account the Windows scaling correctly.

 

[atlopes]

Well, I think you established alöready for yourself that only the foxypreviewer report engine (preview) is rendering a report correctly when Windows text scaling is >100%.
The VFP9 report egine, no matter if from the orignal VFP, SP1 or 2 or the latest hotfix, all versions of that don't take into account the Windows scaling correctly.

Chris,

As long as the executable declares its DPI-Awareness, the standard VFP9 report engine produces a correct output.

This can be demonstrated by the code posted in the [URL='

https://www.tek-tips.com/threads/report-behavior-when-sending-to-pdf.1798781/post-7453555'

]thread [/URL]I mentioned above.

 

[TinyNinja]

Hey EinTerraner, I was just testing with the MS-PrintToPDF and the problem happened with all the printer options I used. Thanks for the code example, it is similar to what I have used in the past. The foxypreviewer app fixes everything and I see the entire PDF correctly.

Hey Chris, Yep Foxypreviewer does what is needed and fixes the Window scaling issue.

Hey atlopes, thank you for the linking thread. If my code starts to act up then I will add your DPI code into my code to have it fix things.