Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
vfp9 Reportgenerator
- Thread starter Ruedi61
- Start date
Mike Lewis
Programmer
I am not seeing that.
Where are setting the "display zoom"? I am not aware of any such setting.
And what exactly do you mean by "vfp9 Reportgenerator"? There is a report designer, which you open with [tt]MODIFY REPORT[/tt]. And there is a report wizard, available from the Tools menu. Are you referring to one of those tools? If not, what?
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #3
Mike Lewis
Programmer
The desktop display settings have got nothing to do with Visual Foxpro. They are part of Windows. If you increase the zoom factor there, everything will appear larger. But only on the screen. They don't affect printed output.
Perhaps you are "printing" to a PDF, and viewing the PDF on the screen? In that case, of course it will appear larger - that's the whole reason for changing the display settings.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Perhaps you are "printing" to a PDF, and viewing the PDF on the screen? In that case, of course it will appear larger - that's the whole reason for changing the display settings.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #5
Hello Mike
Hello everybody
I have created a simple demo that shows the effect. I would be very grateful if someone could help me.
Here der Link:
Greetings from Switzerland
Ruedi
Hello everybody
I have created a simple demo that shows the effect. I would be very grateful if someone could help me.
Here der Link:
Greetings from Switzerland
Ruedi
Mike Lewis
Programmer
Ruedi,
Your screenshot was helpful. It shows that, when you say "report output will also be increased by 125%", you are referring to the report's on-screen preview.
What you are seeing is exactly what you would expect. When you use the display settings in Windows to increase the size of the text on the screen, it applies throughout the Windows session - in VFP and in all other applications. And that of course includes the VFP report preview window.
If that's not what you want, then you should leave the display setting at 100%. Also, of course, you can vary the zoom within the report preivew window itself, using the combo box in the Report Preview toolbar.
Note that this does not affect printed output. The printout will be at the point size of the fonts you used in the report. Also, it won't affect what users see on other computers. If you distribute your application, what the users see will depend on how they have set their own display properties (which, again, is exactly how it should be).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Your screenshot was helpful. It shows that, when you say "report output will also be increased by 125%", you are referring to the report's on-screen preview.
What you are seeing is exactly what you would expect. When you use the display settings in Windows to increase the size of the text on the screen, it applies throughout the Windows session - in VFP and in all other applications. And that of course includes the VFP report preview window.
If that's not what you want, then you should leave the display setting at 100%. Also, of course, you can vary the zoom within the report preivew window itself, using the combo box in the Report Preview toolbar.
Note that this does not affect printed output. The printout will be at the point size of the fonts you used in the report. Also, it won't affect what users see on other computers. If you distribute your application, what the users see will depend on how they have set their own display properties (which, again, is exactly how it should be).
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
- Thread starter
- #7
Thany You Mike
Unfortunately my problem is not solved, because our customers want to enlarge the zoom because they use larger screens.
A zoom from the screen may not affect the printout on paper.
Maybe someone else has a solution to the problem?
Greetings Ruedi
Unfortunately my problem is not solved, because our customers want to enlarge the zoom because they use larger screens.
A zoom from the screen may not affect the printout on paper.
Maybe someone else has a solution to the problem?
Greetings Ruedi
Olaf Doschke
Programmer
This is only a design time problem.
I can reproduce this within the IDE just printing HOME()+"TOOLS\FILESPEC\90FRX.FRX" but the problem went away running the same report within an EXE.
See "Programs should respect "real" screen DPI at runtime instead of the design-time 96 DPI."
Programs do, but only within the runtime, not in vfp9.exe at design time, so you can't run and test and debug reports in the IDE in that display mode, but it'll work as expected within an EXE.
So you need at least SP1, better yet upgrade to SP2 and Hotfix3, anyway, if you didn't already do so.
Two installs, first SP2: then Hotfix 3:
Bye, Olaf.
PS: Your customer has another problem, if graphic drivers act like mine. While the real display resolution stays at 96dpi and at its resolution (HD in my case), any bitmaps are upscaled and when that is done with the effort of smooting them, they look worse than pixelated with a normal 1:1 pixel upscaling, and GDI+ seems to do that. Some fonts look clear, they must be drawn as vector graphics, which scale up well. Other fonts not, which could be related to many ttf fonts using bitmaps for screen and for low fontsizes instead of the scalable vector graphics, which actually defines them.
I can reproduce this within the IDE just printing HOME()+"TOOLS\FILESPEC\90FRX.FRX" but the problem went away running the same report within an EXE.
See "Programs should respect "real" screen DPI at runtime instead of the design-time 96 DPI."
Programs do, but only within the runtime, not in vfp9.exe at design time, so you can't run and test and debug reports in the IDE in that display mode, but it'll work as expected within an EXE.
So you need at least SP1, better yet upgrade to SP2 and Hotfix3, anyway, if you didn't already do so.
Two installs, first SP2: then Hotfix 3:
Bye, Olaf.
PS: Your customer has another problem, if graphic drivers act like mine. While the real display resolution stays at 96dpi and at its resolution (HD in my case), any bitmaps are upscaled and when that is done with the effort of smooting them, they look worse than pixelated with a normal 1:1 pixel upscaling, and GDI+ seems to do that. Some fonts look clear, they must be drawn as vector graphics, which scale up well. Other fonts not, which could be related to many ttf fonts using bitmaps for screen and for low fontsizes instead of the scalable vector graphics, which actually defines them.
Rüdi,
This can be done easily with FoxyPreviewer, download from VFRX at install FoxyPreviewer.app in your Path and than run:
the different zoomlevels parameter can be found at:
Please report back if you encounter problems with this solution.
Regards,
Jockey(2)
This can be done easily with FoxyPreviewer, download from VFRX at install FoxyPreviewer.app in your Path and than run:
Code:
Use x
Do "foxypreviewer.app"
With _Screen.oFoxyPreviewer
.nZoomLevel = 6
Endwith
Report Form x Preview
Return .F.the different zoomlevels parameter can be found at:
Please report back if you encounter problems with this solution.
Regards,
Jockey(2)
Mike Lewis
Programmer
I don't disagree with that, Jockey. But if you only want to get different zoom levels in the preview window, you can do that in the native VFP (9.0) preview.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Olaf Doschke
Programmer
It really is a preview bug in the IDE, nothing less. Not a misunderstanding. If you enlarge the size of fonts, apps and other elements via Windows display settings - in short set the dpi different than the usual 96dpi, the VFP IDE renders reports wrong, a report running rom a compiled EXE does respect the different dpi setting. By the way, todays devices have much higher dpi or ppi, not only printers, and scanners, who had much higher resolutions, still the system mainly calculates things with 96dpi, and so does the VFP IDE.
Bye, Olaf.
Bye, Olaf.
Hi Olaf,
Sorry, I dont see any request for enlarging the fonts here. Rüdi wants to enlarge the preview window and claims when doing so also the output is enlarged. Now this is not true, I have showed him with a small piece of code, in my case using FoxyPreviewer, Mike has a possibility to do the same without FP.
There is no topic about a bug in the VFP reportwriter. The reportwriter does go wrong when you enlarge via Windows display settings. If you only want reports to be shown enlarged than it is not a good idea to change Windows display settings, as this will change your overall settings which I donot believe you would like that to happen.
Regards,
Jockey(2)
Sorry, I dont see any request for enlarging the fonts here. Rüdi wants to enlarge the preview window and claims when doing so also the output is enlarged. Now this is not true, I have showed him with a small piece of code, in my case using FoxyPreviewer, Mike has a possibility to do the same without FP.
There is no topic about a bug in the VFP reportwriter. The reportwriter does go wrong when you enlarge via Windows display settings. If you only want reports to be shown enlarged than it is not a good idea to change Windows display settings, as this will change your overall settings which I donot believe you would like that to happen.
Regards,
Jockey(2)
Olaf Doschke
Programmer
Jockey, did you donwnload the attachment of Ruedis post 14 Mar 17 09:06?
That explains a lot. You will never understand the problem, if you havent looked at that.
Ruedi was always talking about this setting, not the preview Zoom.
If you do this setting ans start a report in VFP9 IDE vs in a VFP9.exe you will see a diffeernet behaviour.
Within the IDE you have to keep this Window setting at 100% (corresponds to 96 dpi). Any end user can have the setting as he likes, as the vfp9r.dll renders correctly.
It's not just like Mike assumed, this setting is blowing up anything, in the IDE it keeps the preview page canvas same size but the content grows and is clipped, which is wrong. It is printed correct anyway. But compiling the same code and running an EXE, both preview and print are OK, so this is just an IDE bug. Most probably the VFP9 team working on the SP2 already didn't have the budget to fix both the runtime and the IDE, though both should have mostly the same code base.
Bye, Olaf.
That explains a lot. You will never understand the problem, if you havent looked at that.
Ruedi was always talking about this setting, not the preview Zoom.
If you do this setting ans start a report in VFP9 IDE vs in a VFP9.exe you will see a diffeernet behaviour.
Within the IDE you have to keep this Window setting at 100% (corresponds to 96 dpi). Any end user can have the setting as he likes, as the vfp9r.dll renders correctly.
It's not just like Mike assumed, this setting is blowing up anything, in the IDE it keeps the preview page canvas same size but the content grows and is clipped, which is wrong. It is printed correct anyway. But compiling the same code and running an EXE, both preview and print are OK, so this is just an IDE bug. Most probably the VFP9 team working on the SP2 already didn't have the budget to fix both the runtime and the IDE, though both should have mostly the same code base.
Bye, Olaf.
Olaf,
Hmm, I did download and unzipped and (shame) never looked at the documents 'myProblem.PDF' or 'myProblem.docx'. Just opened and studied the x.prg. Now I see what is going on, and sure my advise using FoxyPreviewer does not solve his his problem and again it does.
I was wrongly orientated with the opening sentence
Again this proofs: do not modify the windows settings in an application, this is for endusers only.
Now to get the desired result Rüdi is looking for, he should either use FoxyPreviewer or Mike's solution to have a display at a bigger size.
Regards,
Koen
Hmm, I did download and unzipped and (shame) never looked at the documents 'myProblem.PDF' or 'myProblem.docx'. Just opened and studied the x.prg. Now I see what is going on, and sure my advise using FoxyPreviewer does not solve his his problem and again it does.
I was wrongly orientated with the opening sentence
.Ruedi said:
Again this proofs: do not modify the windows settings in an application, this is for endusers only.
Now to get the desired result Rüdi is looking for, he should either use FoxyPreviewer or Mike's solution to have a display at a bigger size.
Regards,
Koen
Olaf Doschke
Programmer
Well, yes and no.
If you read my advice, you would know the problem you see only is happeing in the IDE, once you the same report without changing anything, you get no false zooming and more important no clipping of the objects and text on the report. So it#s merely a problem of the IDE.
You gotta take the sinlge lesson from this, that the VFP IDE is bound to a seteting of 100% here, to work as expected, but you can let end user change this setting without much harm. I still think there are some minor quirks, I rmember page tabs of pageframes not rendered correctly at the 125% or higher setting. And that's it in regard to the problem.
Yes, the windows setting itself is saying 100% is recommended and there are good reasons you can see, if you change it. You reveal all kinds of software not really paying any attention to this setting, and it's not only the developers to blame. Name any function or command really on this topic in the VFP language. Or any programming language. Windows has only achieved halfways working correctly in that changed display mode, Apple has made the full move to les spixel and more resolution dpi or call it ppi relaed display of UI. the forced some less bitmap and more vector oriented UI on apple developers.
My guess is, still much coded is hardwired to work on the 96dpi setting or doesn't care about what the OS does in that regard at all. The topic is very complex. If you remember the iPAD 2 had quadruple solution (2x in both directions = 4x as much pixels), but any software not built for iPAD2 was compatibnle by the iOS simply resizing bitmaps to 2x2 size, so iPAD2, unless you built some confirmation of the higher resoltion into the app, was still reporting the same display ersolution to your app, though in fact it was quadruples. It was nice in the aspect the quadrupling has not much of a blurry effect other than 96dpi vs 221dpi or any such resolutions, which are not a simple multiple of 96dpi.
In the end seeking for better displays for aged people is seeking for bigger screens, really physically bigger screens. Higher resolutions only lead to more sharp edges in some aspects of UI, not in all, in many senses a higher resolution juist leads to smaller text and that is the core problem Ruedi faced. The good news is, VFP is prepared for that in its runtime, but only in its runtime.
Bye, Olaf.
If you read my advice, you would know the problem you see only is happeing in the IDE, once you the same report without changing anything, you get no false zooming and more important no clipping of the objects and text on the report. So it#s merely a problem of the IDE.
You gotta take the sinlge lesson from this, that the VFP IDE is bound to a seteting of 100% here, to work as expected, but you can let end user change this setting without much harm. I still think there are some minor quirks, I rmember page tabs of pageframes not rendered correctly at the 125% or higher setting. And that's it in regard to the problem.
Yes, the windows setting itself is saying 100% is recommended and there are good reasons you can see, if you change it. You reveal all kinds of software not really paying any attention to this setting, and it's not only the developers to blame. Name any function or command really on this topic in the VFP language. Or any programming language. Windows has only achieved halfways working correctly in that changed display mode, Apple has made the full move to les spixel and more resolution dpi or call it ppi relaed display of UI. the forced some less bitmap and more vector oriented UI on apple developers.
My guess is, still much coded is hardwired to work on the 96dpi setting or doesn't care about what the OS does in that regard at all. The topic is very complex. If you remember the iPAD 2 had quadruple solution (2x in both directions = 4x as much pixels), but any software not built for iPAD2 was compatibnle by the iOS simply resizing bitmaps to 2x2 size, so iPAD2, unless you built some confirmation of the higher resoltion into the app, was still reporting the same display ersolution to your app, though in fact it was quadruples. It was nice in the aspect the quadrupling has not much of a blurry effect other than 96dpi vs 221dpi or any such resolutions, which are not a simple multiple of 96dpi.
In the end seeking for better displays for aged people is seeking for bigger screens, really physically bigger screens. Higher resolutions only lead to more sharp edges in some aspects of UI, not in all, in many senses a higher resolution juist leads to smaller text and that is the core problem Ruedi faced. The good news is, VFP is prepared for that in its runtime, but only in its runtime.
Bye, Olaf.
- Thread starter
- #16
Olaf Doschke
Programmer
Please reread the thread.
It's only a bug of the IDE, not when you compile and run the same code compiled as EXE with vfp9r.dll. You just have to be at SP1 at minimum, because it fixes that bug, you better are at SP2 Hotfix3 anyway.
Yes, foxyprevieweer doesn't make a difference. Within IDE you have to have the 100% setting in the OS to see the preview correctly, there is nothing "fixing" this, also none of the hotfixes, the preview fix only is within the vfp9r.dll version SP1, SP2, SP2 Hotfix1-3.
After you build an EXE, the preview will run OK.
I said all this in other words already in my post from 15 Mar 17 07:24
And to be clear: there is no fix for the IDE. Foxypreviewrs preview could be changed, but I wouldn't do so, because that'll just cause previews to become too small when running in the runtime later, as that scales things down. So you better not touch this, you better develop at 100% or live with not seeing the runtime behavior while developing, knowing there is no problem after build.
There is nothing know to fix the IDE and have the smae behaviour at runtime, so you better live with it the way it is, it is much more important the previews are okay for end users running your EXE.
Bye, Olaf.
Perhaps I should ask you, whether you understand some terms. Do you understand what the IDE is? And what the runtime is?
It's only a bug of the IDE, not when you compile and run the same code compiled as EXE with vfp9r.dll. You just have to be at SP1 at minimum, because it fixes that bug, you better are at SP2 Hotfix3 anyway.
Yes, foxyprevieweer doesn't make a difference. Within IDE you have to have the 100% setting in the OS to see the preview correctly, there is nothing "fixing" this, also none of the hotfixes, the preview fix only is within the vfp9r.dll version SP1, SP2, SP2 Hotfix1-3.
After you build an EXE, the preview will run OK.
I said all this in other words already in my post from 15 Mar 17 07:24
And to be clear: there is no fix for the IDE. Foxypreviewrs preview could be changed, but I wouldn't do so, because that'll just cause previews to become too small when running in the runtime later, as that scales things down. So you better not touch this, you better develop at 100% or live with not seeing the runtime behavior while developing, knowing there is no problem after build.
There is nothing know to fix the IDE and have the smae behaviour at runtime, so you better live with it the way it is, it is much more important the previews are okay for end users running your EXE.
Bye, Olaf.
Perhaps I should ask you, whether you understand some terms. Do you understand what the IDE is? And what the runtime is?
- Status
Similar threads
