Report Print Preview size limited to 6.7 inches

[mstrcmtr]

In following Model of HP facing problem of Report Print Preview size limited to 6.7 inches

Report Design in A4 page layout but on Print Preview showing only 6.7 inches on other computers showing report ok

Tested on Printers HP-P1102 and HP-M125a on both Preview upto 6.7 inches

Both Portrait and Landscape having same cutting issue

HP- HQTRE71025

Processor : Inter Core I5 - 6200U , CPU @2.30 GHz
Memory : 8 GB
System type: 64 bit , x64 based processor

Windows 10 Home

 

[Mike Lewis]

What are you expecting the page width to be? What are your settings for column width, left margin and print area (printable page vs. whole page)? (These are all settings in Report Properties.)

Also, are you sure you do not have an embedded Printer Environment? (In the Report Designer, remove the tick against Printer Environment in the Report menu.)

Finally, when you say "Print Preview showing only 6.7 inches", you are referring to the width of the page (as shown by the horizontal ruler)?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[mstrcmtr]

As mentioned above in this Particular Laptop of Hp with OS windows 10 Home only facing the problem other systems and laptops are viewing and printing that reports okay only that Laptop Shrinking reports width to approx 6.7 inches.

As you mentioned Printer Environment in the Report menu not selected

Strange issue whether with Windows 10 Home or Else can't troubleshoot the issue

 

[Mike Lewis]

Can you try running the report on another Windows 10 machine? That would at least tell you whether the problem lies in the Windows version or some other factor?

Also, could you clarify what you mean by "shrinking"? Do you mean that entire report is made smaller, with all the text still appearing but much smaller than expected? Or is the text the correct size but with nothing appearing to the right of the 6.7 inches (as if you had a very wide right margin)?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Just a shot in the dark, if it's not due to a printer environment or report margin /print area settings:

The very general Display setting of Windows in regard of text size will influence a report preview, too. When you set anything else but 100% you get a wrong preview within VFP, that'll be okay within the EXE you build, though.

Bye, Olaf.

 

[mstrcmtr]

In windows 10 other then Home edition Print Preview of reports are Okay

Report Design on A4 size with Portrait and printable page setting

Printer Environment in the Report menu not selected

All above setting show 7.9 inches Width in Print Preview BUT in Win-10 Home edition shows 6.7 inches due to which lost last 2-3 columns printing

 

[mstrcmtr]

Problem Resolved

In Win-10 any edition display setting on 1920 * 1080 making problem when change setting to 1360 * 768 then print Preview showing okay Width of A4 Size page or any page size

 

[Olaf Doschke]

That can be related to what I said. If you only can set higher resolutions on computers be emulating them or turning zo a scrollable display, the text resizing feature of windows can play a role.
If that happens in the EXE you may not use the latest SP2 runtimes.

Bye, Olaf.

 

[mstrcmtr]

Using VFP9SP2RT.Exe Dated 10-Oct-2012

Please give updated link of this file

 

[Olaf Doschke]

That's the runtime installer ProLib has done. It only installs the runtimes, it doesn't update your IDE.

What's VERSION(4)? for you. With SP2 it would be 09.00.0000.5812, IIRC and with the latest hotfix it would be 9.00.0000.7423 as I have.

And once you have your IDE to that version your runtimes installed with it also are at that level. You can't just update the behaviour of an EXE with updating the runtimes only, that works with some parts, as the bytecodes for commands stay and so the IDE could even be lower, but it also is recommended to create the EXE with the same version as the runtime used for execution. I had C5 errors when having a mismatch there, and so I wouldn't be surprised bugfixes not working or only working, if compiled and executed with a certain version.

The absolutely latest hotfix is here:

https://github.com/VFPX/VFP9SP2Hotfix3

The prerequisite for applying it is having VFP9 at SP2 level, so VERSION(2) must be 2 before applying that. And than you might get better results after recompiling and running the EXE with the updated runtime vfp9r.dll Prouct Version 9.0.00.7423, too.

Bye, Olaf.

 

[mstrcmtr]

Is it necessary to install this HotFix3 Update on Client Pc as well

Installing VFP9Sp2RT on client Pcs before running Compiled Exe

I Checked that same version of file vfp9r.dll already installed on my pc that is hotfix 3 then why facing Report Width Issue in Win-10

 

[Olaf Doschke]

OK, let's simply make this as clear as mud:

The hotfix is updating (fixing) your VFP installation, so you only install it on your dev pc. This is an IDE update, not a runtime installer.

The hotfix ALSO updates the runtime DLLs in Microsoft Shared/VFP folder (within Program Files x86) on your dev pc, but again: It is no runtime installer, it has the IDE as the prerequisite to run at all, so you can't install it on clients anyway. It enables you to compile code in and for that version. But that upgrade of the dev pc runtimes allows you to get what you need on clients, too.

Because on clients, these updated runtime DLLs and reportoutput.app have to be installed plus your rebuilt EXE.

That's all you need to know. In summary, you install the hotfix on your dev pc, rebuild your EXE and provide it to clients with the upgraded vfp9r.dll, reportoutput.app and anything else necessary.

In more detail:

The runtime installers of which you have one, are only there to simplify the distribution process for devs not able or not wanting to create a setup, which of course needs elevation once to run, that's then reduced to once (for the runtime installer itself) for all EXEs you put on that client from then onwards. But a) when you do your own setups with InstallShield or Inno you don't need any RT installer as that setup can installs RTs, too, also registered for all or just into your application folder and b) you also don't need the RT installer when you make the simplest distribution with your EXE plus the 2-3 DLLs side by side, they don't need registering, so you can install VFP code without admin permissions at all, only not in Program Files, as putting files there already needs elevated permissions.that means you can mix 9SP0,1,2 with or without hotfixes as necessary for each indiidual EXE.

The runtime installers used at clients do install the same SP/hotfix level in a place found by any EXE or COM DLL not having their own runtime side by side to it and thus you will for sake of a clean setup need to upgrade all executables when going the route of the runtime installers. You can individually make some EXEs use other runtime DLLs by putting them side by side, I think (not 100% sure) those are taken with the highest priority before searching registry for the runtime location.

Anyway, you CAN, if you find it, use the similar runtime installer for SP2 Hotfix3 and install it on clients, you just need to be aware those are then used for any VFP9 executable and may cause C5, when an EXE is compiled in SP0, SP1 or even SP2 but without the hotfix 3, so I'd not upgrade clients this way. The runtime installers are good for servers you only get permission to set up once with an on-site admin and you only want to use one executable an be able to upgrade that later without admin permission, though you can also go the simplest route of putting DLLs side by side to your EXE. The runtime installers are not good in my opinion for generally enabling a client to run any VFP executables as they don't allow the mixed mode within each major VFP version. Of course the situation is simpler in case you have several executables in different major VFP versions, a VFP6.exe will not look for a VFP9 runtime, although that could execute most any VFP6 (or 4,5,7,8) bytecode, the major version numbers are in the runtime DLL files, but not so SP and Hotfix levels, that's the pure reason behind all that.

You have to know VFP doesn't compile into assembler, it compiles to a bytecode that then is read and interpreted by runtimes. There are mostly constant bytecodes for same commands throughout all VFP versions, which is why a VFP6 compiled executable also can run with a VFP9 runtime DLL, as long as all bytecodes have stayed downward compatible. It won't do so in an EXE, but when you call into a class or procedure of a VFP6 APP file, you can run that with VFP9R.DLL, too. There are changes in parameterization along VFP versions, that limit that kind of downward compatibility. Don't mind, if you don't get what bytecode is, it boils down to the best practice not making use of these quirks and just using exact same RT version as used for compilation ideally, even though some things also work with older EXE code using newer runtimes. The main fixes of behavior surely are in the runtime DLL, as it has the real executable code. The EXE you compile just tells the runtime DLL which of his internal function and command implementations to execute. The only part really executable from your built EXE is a part of compiled C++ loading the VFP runtime and starting up the program execution, pointing the VFP program counter to the start of main. That together means an updated runtime executes fixed versions of functions and commands and report apps, but if anything changes in bytecode even just the parameterization order, the fixed runtime code only runs, when finding that newer bytecode version, too. That's how I at least explain the C5 cases I had with mismatches, something then was so weird even causing fatal errors, just like a not found entry point/address.

The only situations you really need a setup making this an official Windows installed software seen on features and programs for uninstallation, too, is when you want that to be listed there and when you have more advanced steps to do like registering an ActiveX control or OLE server or adding some registry data or many other things needing elevated admin permissions, which normal users won't have after the setup just starting your EXE. So the simplest setup with EXE+DLLs in one folder is really efficiently getting you the desired runtime usage. The only downside of that procedure is when using CHM and HELP commands of VFP, as they need a registered foxhhelp EXE and any OLE/COM stuff you then can't use or need to prepare with a separate setup.

Bye, Olaf.