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 TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Print control in foxypreviewer 1
- Thread starter Rhtt
- Start date
Mike Lewis
Programmer
Rhtt,
Your program needs a component named ReportPreview.App. By default, this is located in your main VFP9 directory. If you have moved it to another location, you must make sure that your program can find it.
When distributing an EXE to other users, you need to make sure that ReportPreview.App is available. You can either distribute ReportPreview.App with your EXE, or you can add it to your project before you do the build, in which case it will be bound into the EXE.
_REPORTPREVIEW contains the path and name of the app file. If your program still cannot find it, try putting a messagebox in the program, immediately before the DO (_REPORTPREVIEW) line, to display the contents of _REPORTPREVIEW. That will tell you if the program is looking in the right place.
For more information, see these Help topics:
[ul]
[li]_REPORTPREVIEW System Variable[/li]
[li]Including Report Files for Distribution[/li]
[/ul]
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Your program needs a component named ReportPreview.App. By default, this is located in your main VFP9 directory. If you have moved it to another location, you must make sure that your program can find it.
When distributing an EXE to other users, you need to make sure that ReportPreview.App is available. You can either distribute ReportPreview.App with your EXE, or you can add it to your project before you do the build, in which case it will be bound into the EXE.
_REPORTPREVIEW contains the path and name of the app file. If your program still cannot find it, try putting a messagebox in the program, immediately before the DO (_REPORTPREVIEW) line, to display the contents of _REPORTPREVIEW. That will tell you if the program is looking in the right place.
For more information, see these Help topics:
[ul]
[li]_REPORTPREVIEW System Variable[/li]
[li]Including Report Files for Distribution[/li]
[/ul]
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Are you serious that your posted code works at all, no matter if compiled or running within the IDE?
This line is nonsensical:
And the next line makes no sense, too.
Again, don't use your own preview at all. If you want to influence the print button from the foxypreviewer print toolbar by setting the _Screen.oFoxyPreviewer.lShowPrintBtn = .F. and then also use the Foxypreviewer preview window simply by having the PREVIEW clause in your REPORT FORM command.
It's really as simple as that, if you want a preview without print button:
That prints to a pdf file, it automatically detects that it has to use the foxypreviewer PDF listener. You're already sabotaging this by using your own reportlistener object. You're not using foxypreviewer at all with your code.
besides that, as Mike already explained to you, of course the app files about the report engine play a role. If you use the native report engine of VFP9 that's three app files instread of just one. And of course they have to be present in the EXE folder during EXE run, and you have to set default to that folder or provide a path to the foxypreviewer.app file when you DO it. When using the VFP native report engine the reportpreview.app and reportoutput.app that are within the VFP HOME() folder have to be copied there as minimum.
Have you read anything about using VFP9 reporting at all? Ar the section "What's new in VFP9 in the VFP9 help? Then you'd know about the apps and what you have to do with them.
Chriss
This line is nonsensical:
Code:
loPreview loPreview = NULLAgain, don't use your own preview at all. If you want to influence the print button from the foxypreviewer print toolbar by setting the _Screen.oFoxyPreviewer.lShowPrintBtn = .F. and then also use the Foxypreviewer preview window simply by having the PREVIEW clause in your REPORT FORM command.
It's really as simple as that, if you want a preview without print button:
Code:
DO foxypreviewer.app
_Screen.oFoxyPreviewer.lShowPrintBtn = .F.
REPORT FORM myreport PREVIEW TO FILE "my.pdf"That prints to a pdf file, it automatically detects that it has to use the foxypreviewer PDF listener. You're already sabotaging this by using your own reportlistener object. You're not using foxypreviewer at all with your code.
besides that, as Mike already explained to you, of course the app files about the report engine play a role. If you use the native report engine of VFP9 that's three app files instread of just one. And of course they have to be present in the EXE folder during EXE run, and you have to set default to that folder or provide a path to the foxypreviewer.app file when you DO it. When using the VFP native report engine the reportpreview.app and reportoutput.app that are within the VFP HOME() folder have to be copied there as minimum.
Have you read anything about using VFP9 reporting at all? Ar the section "What's new in VFP9 in the VFP9 help? Then you'd know about the apps and what you have to do with them.
Chriss
- Thread starter
- #23
Chris Miller
Programmer
Okay, I tested it, and it really depends on whether you want to work with the free version 2.99 or version 3.
I downloaded version 2.99z41 (FoxyPreviewer v299z41.zip) and extracted it into the folder C:\Users\ChrissM\Downloads\FoxyPreviewer v299z41And I downloaded version 3.165 (FoxyPreviewer_v3.165 Distrib.zip) and extracted it into the folder C:\Users\ChrissM\Downloads\FoxyPreviewer_v3.165 Distrib
In version 2.99 the code I gave will give you what you want: A preview with a toolbar that does not show the "print report" button. There's a crux with this, because you actually DO need this button to finally create the PDF after the preview.
In version 3 using this code does not provide the FoxPro report preview feature, but opens up the PDF application associated with the PDF extension after creating the PDF file. It should be sufficient, as that should be your goal, to let the user see the PDF not just a preview of the PDF. The code for that is not needing to influence the preview windows, it doesn't even need a preview window at all, neither your own nor the FoxyPreviewer internal preview window. It creates the PDF and afterward opens it. The UI you get then depends solely on the PDF application associated with the computer. So it even reduces to a two-liner:while
Both versions of FoxyPreviewer use the libhpdf.dll, by the way. This will be extracted from the foxyPreviewer app when it's needed, you don't need to add that yourself. There is another crux with this, though, if your final installed version can't write out the DLL it extracts from the APP, then this is a reason it only works in the IDE and not in the final version.
Using foxypreviewer app also comes with using FoxyPreviewer_Settings.dbf table, that should be a writable file. So overall for the final distributon, it's always best to have the app in a folder users can write to. That's a detail aspect you should also see for yourself, if you use foxypreviewer from the IDE in your first tests, because the zip does not contain the DLL. In v 2.99 you get a Source and Sample subfolder in the zip extraction and in version 3 you get no source subfolder, only the Samples and a FoxyGetImage.prg. Anything else is generated by using foxypreviewer.app
So please, pay attention and observe what happens also on the file/folder level, when you use foxyPreviewer. BEsides reading the documentation, which also tells you that and much more.
All in all it's still not necessary to have your code, you're just doing way too much and not getting what you want, as you use mechanisms like the AllowPrintFromPreview that's taken into account by the native Report engine of VFP9, but not by FoxyPreviewer, which has its own flags for its own preview window toolbar you've been pointed to multple times already.
You first have to decide whether you want to use FoxyPreviewer or not. And then do things accordingly to documentation. You mix sample code meant for the usual report engine with Foxypreviewer samples, this won't work out.
On top of that. If your decision to use the native report engine provided with vfp9 from Microsofts, you will need a PDF printer that you have to set prior to running the report. If you use FoxyPreviewer, you don't it uses a Pdf dll. You will then need different code for version 2.99 or 3 and you either go for using the foxyPreviewer preview before actually generating the PDF or use it to generate the PDF and finally show the PDF file in whatever PDF viewer the computer has associated with the file type PDF.
Chriss
PS: find the PDF of 90frx.frx as a download link, so you see what PDF FoxyPreviewer generates using the libhpdf.dll embedded within the foxypreviewer.app.
I downloaded version 2.99z41 (FoxyPreviewer v299z41.zip) and extracted it into the folder C:\Users\ChrissM\Downloads\FoxyPreviewer v299z41And I downloaded version 3.165 (FoxyPreviewer_v3.165 Distrib.zip) and extracted it into the folder C:\Users\ChrissM\Downloads\FoxyPreviewer_v3.165 Distrib
In version 2.99 the code I gave will give you what you want: A preview with a toolbar that does not show the "print report" button. There's a crux with this, because you actually DO need this button to finally create the PDF after the preview.
In version 3 using this code does not provide the FoxPro report preview feature, but opens up the PDF application associated with the PDF extension after creating the PDF file. It should be sufficient, as that should be your goal, to let the user see the PDF not just a preview of the PDF. The code for that is not needing to influence the preview windows, it doesn't even need a preview window at all, neither your own nor the FoxyPreviewer internal preview window. It creates the PDF and afterward opens it. The UI you get then depends solely on the PDF application associated with the computer. So it even reduces to a two-liner:while
Code:
Do "C:\Users\ChrissM\Downloads\FoxyPreviewer_v3.165 Distrib\FoxyPreviewer.app"
Report Form (Home()+"\TOOLS\FILESPEC\90FRX.FRX") To File ("C:\Users\ChrissM\Downloads\FoxyPreviewer_v3.165 Distrib\90frx.pdf") PreviewBoth versions of FoxyPreviewer use the libhpdf.dll, by the way. This will be extracted from the foxyPreviewer app when it's needed, you don't need to add that yourself. There is another crux with this, though, if your final installed version can't write out the DLL it extracts from the APP, then this is a reason it only works in the IDE and not in the final version.
Using foxypreviewer app also comes with using FoxyPreviewer_Settings.dbf table, that should be a writable file. So overall for the final distributon, it's always best to have the app in a folder users can write to. That's a detail aspect you should also see for yourself, if you use foxypreviewer from the IDE in your first tests, because the zip does not contain the DLL. In v 2.99 you get a Source and Sample subfolder in the zip extraction and in version 3 you get no source subfolder, only the Samples and a FoxyGetImage.prg. Anything else is generated by using foxypreviewer.app
So please, pay attention and observe what happens also on the file/folder level, when you use foxyPreviewer. BEsides reading the documentation, which also tells you that and much more.
All in all it's still not necessary to have your code, you're just doing way too much and not getting what you want, as you use mechanisms like the AllowPrintFromPreview that's taken into account by the native Report engine of VFP9, but not by FoxyPreviewer, which has its own flags for its own preview window toolbar you've been pointed to multple times already.
You first have to decide whether you want to use FoxyPreviewer or not. And then do things accordingly to documentation. You mix sample code meant for the usual report engine with Foxypreviewer samples, this won't work out.
On top of that. If your decision to use the native report engine provided with vfp9 from Microsofts, you will need a PDF printer that you have to set prior to running the report. If you use FoxyPreviewer, you don't it uses a Pdf dll. You will then need different code for version 2.99 or 3 and you either go for using the foxyPreviewer preview before actually generating the PDF or use it to generate the PDF and finally show the PDF file in whatever PDF viewer the computer has associated with the file type PDF.
Chriss
PS: find the PDF of 90frx.frx as a download link, so you see what PDF FoxyPreviewer generates using the libhpdf.dll embedded within the foxypreviewer.app.
Chris Miller
Programmer
Rhtt said:
Good to hear, that you got that working.
But that detail should not be your concern at all because as you initially said:
Then doing the initialization of FoxyPreviewer will set _REPORTPREVIEW and the other report system variables correctly, without you touching them at all:
Code:
DO FoxyPreviewer.appTo see this for yourself, how about trying this:
Code:
? _REPORTBUILDER
? _REPORTPREVIEW
? _REPORTOUTPUT
DO FoxyPreviewer.app
? _REPORTBUILDER
? _REPORTPREVIEW
? _REPORTOUTPUTI think you have now copied the VFP9 REPORTPREVIEW.APP into your distribution/installation directory and set _REPORTPREVIEW to that app. Then you step on your own foot and don't use FoxyPreviewer, even if you initializd it. You should know that, even if everything works out for you right now.
And if I guess wrong, then I wonder why you set _REPORTPREVIEW and to which value. Because as shown, FoxyPreviewer already sets this for itself, there is no need to override that value, if you really want to use FoxyPreviewer. Otherwise, you don't. and you miss out many more features FoxyPreviewer offers than a pdflistener that outputs PDF without the need of a PDF printer. FoxyPreviewer is really an enhanced report preview and output engine that only does not extend the builder=designer of reports, anything else, the preview and output, is enhanced and it even handles the OS scaling factor of fonts correctly. you're really missing out many things because you clerly still don't understand the implications of what you're doing.
Chriss
Mike Lewis
Programmer
Rhtt,
Reading back over this thread, it seems to me that you have been given a lot of advice - perhaps too much advice. Some of it overlaps, some is contradictory, and a lot of it was given without a clear idea of what you wanted to achieve.
Perhaps I could now try to summarise the key points. What follows is the least you need to know:
1. If you decide to use FoxyPreviewer, first copy FoxyPreviewer.App to the root of your development directory (that is, the directory holding your main program, project file, etc).
2. At the start of your main program, do this command: [tt]DO FoxyPreviewer.APP[/tt]
3. When you are ready to preview a report, do this: [tt]REPORT FORM MyReport.FRX PREVIEW[/tt] This will use FoxyPreview to display the preview. Users will be able to save the report to PDF or print it to paper.
4. If you want to hide the printer button in the preview, add this line after Step 2 but before your first preview: [tt]_Screen.oFoxyPreviewer.lShowPrintBtn = .F.[/tt] (this will also hide the Print command on the context menu).
5. If you want to hide the "Save as PDF" option in the preview, add this line after Step 2 but before your first preview: [tt]_Screen.oFoxyPreviewer.lSaveAsPDF = .F.[/tt]
6. If you want to allow the user to print (or save as PDF) once only, then you will have to hide the relevant buttons as per steps 4 and 5, and provide some other way or printing / saving as PDF in your application, separately from the preview.
7. When you are ready to build the executable, add FoxyPreviewer.APP to your project (it will appear under Applications in the Code tab). Check that it is not excluded. Then build the EXE in the usual way. You won't need to give your users a copy of FoxyPreviewer.APP.
I think that covers everything. It will give you the many benefits of using FoxyPreviewer, and still meet your needs regarding limiting the printing and PDF options.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Reading back over this thread, it seems to me that you have been given a lot of advice - perhaps too much advice. Some of it overlaps, some is contradictory, and a lot of it was given without a clear idea of what you wanted to achieve.
Perhaps I could now try to summarise the key points. What follows is the least you need to know:
1. If you decide to use FoxyPreviewer, first copy FoxyPreviewer.App to the root of your development directory (that is, the directory holding your main program, project file, etc).
2. At the start of your main program, do this command: [tt]DO FoxyPreviewer.APP[/tt]
3. When you are ready to preview a report, do this: [tt]REPORT FORM MyReport.FRX PREVIEW[/tt] This will use FoxyPreview to display the preview. Users will be able to save the report to PDF or print it to paper.
4. If you want to hide the printer button in the preview, add this line after Step 2 but before your first preview: [tt]_Screen.oFoxyPreviewer.lShowPrintBtn = .F.[/tt] (this will also hide the Print command on the context menu).
5. If you want to hide the "Save as PDF" option in the preview, add this line after Step 2 but before your first preview: [tt]_Screen.oFoxyPreviewer.lSaveAsPDF = .F.[/tt]
6. If you want to allow the user to print (or save as PDF) once only, then you will have to hide the relevant buttons as per steps 4 and 5, and provide some other way or printing / saving as PDF in your application, separately from the preview.
7. When you are ready to build the executable, add FoxyPreviewer.APP to your project (it will appear under Applications in the Code tab). Check that it is not excluded. Then build the EXE in the usual way. You won't need to give your users a copy of FoxyPreviewer.APP.
I think that covers everything. It will give you the many benefits of using FoxyPreviewer, and still meet your needs regarding limiting the printing and PDF options.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
Visual FoxPro articles, tips and downloads
Chris Miller
Programmer
Mike,
I agree to that and also apologize. I apologize and also I am not offended by this observation - it's simply true. I just have to think about the other long thread about logging.
I also won't add my own summary or even add to yours, it's sufficiently making the important points to think about when using reporting in VFP. since version 9 it has become a bit more complicated, even if you just want to use VFP9's own report engine, as it's now having separate app runtime files. If you don't provide those apps or a replacement like FoxyPreviewer, you end up with the "legacy" report engine that's still also contained in the vfp9r.dll, just to point that thing out.
If you don't even know that major change about the app files and the three _REPORT... system variables and what it means in terms of files to distribute, you also have trouble in getting FoxyPreviewer to work out for you. Foxypreviewer, if used correctly, can make the step from old reporting to new reporting easier, as it even hides the need to know much about the new architecture. you even don't need to know anything about reportlisteners, to use them from FoxyPreviewer. But it still requires you to know about the apps that now handle reporting and if your reporting still was based on not using FRXes at all, but using direct output to printer ports, you're also still two paradigm changes away from the current reporting engine architecture.
Unfortunately, that does not only hit developers that stuck to the old Foxpro versions but developers coming into old projects for maintenance that are still based on old Foxpro version code that hasn't been developed through versions 5-9 at all. you always automatically have trouble if a software product doesn't evolve in parallel to the evolution of the programming language and IDE it's built on. And that's what you often inherit. You can feel praised if you inherit a project that was started with VFP6, even if it is still not making use of all the improvements of VFP7-9, you then mainly already have a Visual Foxpro project. And I don't emphasize visual in its literal meaning here, but the major changes towards an OOP-based programming style with Winforms as the technical platform.
No, Microsoft didn't just take the SQL engine from VFP to put it into Access and MS SQL Server to then scrap VFP, there wouldn't even have been VFP3 if that was the plan. They actually enhanced your opportunities to make a better Windows UI/UX version of your applications and profit from other strategic language enhancements, too. I see little praise and thankfulness for that.
Chriss.
Mike Lewis said:
I agree to that and also apologize. I apologize and also I am not offended by this observation - it's simply true. I just have to think about the other long thread about logging.
I also won't add my own summary or even add to yours, it's sufficiently making the important points to think about when using reporting in VFP. since version 9 it has become a bit more complicated, even if you just want to use VFP9's own report engine, as it's now having separate app runtime files. If you don't provide those apps or a replacement like FoxyPreviewer, you end up with the "legacy" report engine that's still also contained in the vfp9r.dll, just to point that thing out.
If you don't even know that major change about the app files and the three _REPORT... system variables and what it means in terms of files to distribute, you also have trouble in getting FoxyPreviewer to work out for you. Foxypreviewer, if used correctly, can make the step from old reporting to new reporting easier, as it even hides the need to know much about the new architecture. you even don't need to know anything about reportlisteners, to use them from FoxyPreviewer. But it still requires you to know about the apps that now handle reporting and if your reporting still was based on not using FRXes at all, but using direct output to printer ports, you're also still two paradigm changes away from the current reporting engine architecture.
Unfortunately, that does not only hit developers that stuck to the old Foxpro versions but developers coming into old projects for maintenance that are still based on old Foxpro version code that hasn't been developed through versions 5-9 at all. you always automatically have trouble if a software product doesn't evolve in parallel to the evolution of the programming language and IDE it's built on. And that's what you often inherit. You can feel praised if you inherit a project that was started with VFP6, even if it is still not making use of all the improvements of VFP7-9, you then mainly already have a Visual Foxpro project. And I don't emphasize visual in its literal meaning here, but the major changes towards an OOP-based programming style with Winforms as the technical platform.
No, Microsoft didn't just take the SQL engine from VFP to put it into Access and MS SQL Server to then scrap VFP, there wouldn't even have been VFP3 if that was the plan. They actually enhanced your opportunities to make a better Windows UI/UX version of your applications and profit from other strategic language enhancements, too. I see little praise and thankfulness for that.
Chriss.
- Status
Similar threads
