×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Print control in foxypreviewer

Print control in foxypreviewer

Print control in foxypreviewer

(OP)
Hello
I am using foxypreviewer in my app in visual FOXPRO9 for generating an PDF file from report but i need to deactivate print button from that PDF, how can i do that? It is possible to deactivate it?

Thank you!

RE: Print control in foxypreviewer

I don't know what you mean.
You only get a preview and toolbar which have buttons you could suppress, if you don't just print the report, but also use the preview feature.

You can specify all things foxyPreviewer needs to know in advance and just generate a PDF without user interaction, then you don't need to customize the print preview toolbar at all, i.e. that's the ideal solution. Just look into the documentation here in page 51: https://www.foxypreviewer.com/p/foxypreviewer-docu...

Chriss

RE: Print control in foxypreviewer

FoxPreviewer has a couple of properties that control the visibility of print buttons:

lShowPrintBtn: Set it to .F. to hide the Print button. This does not affect other printer-related buttons, such as Printer Preferences.

lPrintVisible: Set to .F. to hide all printer-related buttons.

See the FoxPriveiwer docs for more details.

Of course, this won't prevent the user from printing from within your PDF viewer. There's nothing you can do in VFP to prevent that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

IMHO, Rhtt need disable PRINT button from PDF viever.
FoxyPreviewer use harulib for creating PDF. It's possibly modify class add calls HPDF_SetPermission() functions.
[link https://github.com/libharu/libharu/wiki/APIbig smileocument#user-content-HPDF_SetPermission ]libHaru - HPDF_SetPermission()[/link]

mJindrova

RE: Print control in foxypreviewer

From the docs page 51 (as I recommended to read):

1. lPDFEncryptDocument - logical, determines if the PDF engine will encrypt the PDF document, allowing you to set other restrictions
to the documents, using the properties below
2. lPDFCanPrint - logical, determines if the 'encrypted' PDF document will allow printing. Works only if lPDFEncryptDocument = TRUE
(see above)

So yes, this can be made a feature of the resulting PDF file. You just have to read the documentation. Also in the documentation, how you customize the toolbar and how you don't even need that and determine the PDf file name before printing=generating the file without preview, so the user doesn't pick print (to printer/paper) instead of the save to PDF option.

All things are actually possible. how far the rights management is supported by all pdf viewers after a file is generated encryped and wihtout print permission is beyond my knowledge, though.

Chriss

RE: Print control in foxypreviewer

Quote (Chriss)

how far the rights management is supported by all pdf viewers after a file is generated encryped and wihtout print permission is beyond my knowledge, though
.

Yes, that's the key point. You can't know what PDF viewer your users will be using, and you can't know what features that viewer supports. Also, even if the viewer respects the "no print" setting, that won't prevent a determined user from printing the document. There are several utilities available which "unlock" secure PDFs.

Perhaps Rhtt could clarify: Do you want to remove or disable the print button in Foxy? Or do you want to prevent the user from printing within the viewer?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

(OP)
Hello Mike, i need to disable the print button if that pdf was printed 1 time user cannot be able to print 2 nd time i need that user can only view that pdf not to print it

I try to set lPDFEncryptDocument = TRUE
lShowPrintBtn= .F.
lPDFCanPrint = .f.

but is the same result with no modification

RE: Print control in foxypreviewer

Hello,

maybe you should look in FP doocs for savepropertys, too.

We have a button "preview" which has print and save in FP disabled and sometimes even an additional watermark
and a button "save" which saves without showing the report in preview or "print and save" which additionally prints on "jobprinter" stored in our usersettings.

Regards
tom

RE: Print control in foxypreviewer

Oh I forgot. Permission applied with passwords (PDF) only.
Set owner password to samoe string and user password to empty string.

mJindrova

RE: Print control in foxypreviewer


Quote:

I try to set lPDFEncryptDocument = TRUE
lShowPrintBtn= .F.
lPDFCanPrint = .f.

but is the same result with no modification

Just to be clear: You are saying that, even after setting lShowPrintBtn to .F., you can still see the Print button? Is that correct?

If so, be aware that lShowPrintBtn is a property of the FoxpyPrviewer object. It is not a variable. So instead of this:

lShowPrintBtn= .F.

you need to do this:

_Screen.oFoxyPreviewer.lShowPrintBtn = .F.

You do that any time after you do DO FOXYPREVIEWER.APP and before you invoke the preview.

If that doesn't work, there are other ways of achieving your goal, but try this one first.

Note this has got nothing to do with lPDFEncryptDocument or lPDFCanPrint. Those are also properties of FoxPreviewer, but they don't affect what the user can see or do in the preview window. They affect the actual PDF.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

(OP)
Mike,
The syntax what i used is
_Screen.oFoxyPreviewer. but nothing happen

I'm thinking to use report preview instead of pdf with pdfviewer

But then i need to hide that print button too

RE: Print control in foxypreviewer

I can't see why that shouldn't work. Are you sure your code is correct?

That said, another option would be to output the PDF without the preview. You can do that in FoxyPreviewer, or by "printing" the report to a PDF printer driver.

If you want to provide a preview but without any printing facilities, you can do that in VFP's native preview window. Something like this:

CODE -->

LOCAL loPreview
loPreview = NULL
DO (_REPORTPREVIEW) WITH loPreview

loPreview.AllowPrintFromPreview = .F.
  && This is the important bit

loPreview.AllowPrintFromPreview = .F.
loListener = CREATEOBJECT("ReportListener")
loListener.PreviewContainer = loPreview
lolistener.ListenerType = 1

REPORT FORM MyReport OBJECT loListener 

You could then provide separate buttons somewhere else in your interface to output the report to PDF and to print it. Doing it that way would also allow you to disable the Print button after the user has printed one copy of the report, which I think is what you originally asked for.

But, as I said earlier, none of this will prevent the user from printing the PDF outside your application.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

And if you want to produce the PDF in FoxyPreviewer but without the preview:

CODE -->

REPORT FORM MyReport.FRX OBJECT TYPE 10 TO FILE "MyPDF.PDF" 


Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

Mike, that's all fine, but actually you don't even need a pdf printer driver, as FoxyPreviewer generates PDF with a library directly, you just need to set some properties of the foxyprevviewer object and then print in its PDF mode without a preview.

In the FAQs section of the documentation page https://www.foxypreviewer.com/p/foxypreviewer-docu....


How can I generate a PDF (or any other available type) without opening the preview window ?

In FP v3
Just use the "TO FILE" clause, and FPv3 will use the File extension used to determine automatically the best reportlistener to create your output! In short, in the new version you don't need to use the "OBJECT TYPE" clause at all!

CODE -->

DO FoxyPreviewer.App && only necessary once in main, not for every report
* Make PDF
REPORT FORM yorreport ;
   TO FILE "c:\TestReport.Pdf" 

Chriss

RE: Print control in foxypreviewer

(OP)
Mike

CODE --> vfp9

LOCAL loPreview
loPreview = NULL
DO (_REPORTPREVIEW) WITH loPreview

loPreview.AllowPrintFromPreview = .F.
  && This is the important bit

loPreview.AllowPrintFromPreview = .F.
loListener = CREATEOBJECT("ReportListener")
loListener.PreviewContainer = loPreview
lolistener.ListenerType = 1

REPORT FORM MyReport OBJECT loListener 

i tried your exemple for vfp report but it wont deactivate print button

RE: Print control in foxypreviewer

(OP)
It work now, my bad, thank you so much for y'all help

RE: Print control in foxypreviewer

We now don't know what you finally ended up with, but what you showed was still not using the essential line of code necessary to use foxypreviewer at all.

If you want to use foxypreviewer the starting point is having this line of code

CODE

DO FoxyPreviewer.App 
Has that at least become clear by now?

And then you can use reports a you did without foxypreviewer and you have some more properties/settings and also the TO FILE clause of REPORT commands will make foxypreviewer process that as necessary. Without a reportlistener, without an OBJECT clause.

What you have there is likely sample code for usage of older foxypreviewer versions. It'll also work for downward compatibility, but all in all foxypreviewer usage is much simpler as even Mike told you. Haven't you found the paragraph I quoted from the documentation?

I even highlighted the quoted portion saying you don't need the OBJECT TYPE clause. Thus you also don't need a reportlistener object. Foxypreviewer is triggered, can analyze the code and clauses and then use its own appropriate reportlistener, for example for generating PDF. If you use your own, I bet it'll override that anyway. And a base class reportlistener. Which has no implementation that makes it do anything special like creating HTML or DOC or PDF output. If you use a reportlistnere, then it's always a class derived from the reportlistener, that actual has some code in events and methods that does something different than the usual report engine does.

Chriss

RE: Print control in foxypreviewer

I use the below together with other code, to produce a PDF that can be previewed with no PRINT button on the toolbar:

*This is at the start of my prg

CODE -->

#DEFINE PrintFromPreview .F.

LOCAL loPreviewContainer AS FORM, ;
  loReportListener AS REPORTLISTENER, ;
  loExHandler AS ExtensionHandler OF SYS(16)

loPreviewContainer = NULL
DO (_REPORTPREVIEW) WITH loPreviewContainer
loReportListener = NEWOBJECT('ReportListener')
loReportListener.LISTENERTYPE = 1 &&Preview
loReportListener.PREVIEWCONTAINER = loPreviewContainer
loPreviewContainer.AllowPrintfromPreview = PrintFromPreview
loPreviewContainer.TextOnToolbar = .F.
loExHandler = NEWOBJECT('ExtensionHandler')
loPreviewContainer.SetExtensionHandler( loExHandler ) 

* The following command is later issued


CODE -->

REPORT FORM MYFORM NOCONSOLE PREVIEW FOR SOMETHING=msomething OBJECT loReportListener  && Example only 


* The below is at the end of my prg

CODE -->

DEFINE CLASS ExtensionHandler AS CUSTOM
  *-- Ref to the Preview Container's Preview Form
  PreviewForm  = NULL

  *-- Here you implement (hook into) the PreviewForm_Assign
  *-- event of the preview container's parent proxy

  PROCEDURE PreviewForm_Assign( loRef )
  *-- Perform default behavior: assign obj ref.
  THIS.PreviewForm = loRef

  *-- Grab the obj ref to the preview form and bind to its
  *-- ShowToolbar() method. This lets the
  *-- STB_Handler() method of this extension handler
  *-- to run code whenever the Preview toolbar is shown
  *-- by the PreviewForm.ShowToolbar() method.
  IF !ISNULL( loRef )
    BINDEVENT(THIS.PreviewForm, ;
    'ShowToolbar', THIS, 'STB_Handler')
  ENDIF
  ENDPROC

  PROCEDURE STB_Handler(lEnabled)
  *-- Here you work around the setting
  *-- persistence problem in the Preview toolbar. 
  *-- The Preview toolbar class (frxpreviewtoolbar)
  *-- already has code that you can use to enforce
  *-- setting's persistence; it is just not called. Here,
  *-- you call it.
  WITH THIS.PreviewForm.TOOLBAR
  .REFRESH()
  *-- When you call frxpreviewtoolbar::REFRESH(), the
  *-- toolbar caption is set to its Preview form,
  *-- which differs from typical behavior. You must revert that
  *-- to be consistent. If you did not do this,
  *-- you would see " - Page 2" appended to the toolbar
  *-- caption if you skipped pages.
  .CAPTION = THIS.PreviewForm.formCaption
  ENDWITH
  ENDPROC

  *-- A preview container requires these methods
  *-- to be implemented in an associated preview extension handler.
  *-- They are not used in this example, but still must be here.
  PROCEDURE AddBarsToMenu( cPopup, iNextBar )
  PROCEDURE SHOW( iStyle )
  ENDPROC
  PROCEDURE HandledKeyPress( nKeyCode, nShiftAltCtrl )
  RETURN .F.
  ENDPROC
  PROCEDURE PAINT
  ENDPROC
  PROCEDURE RELEASE
  RETURN .T.
  ENDPROC

ENDDEFINE 

I see you've already mentioned you resolved your question but it might be useful to tell us what you did.

Thank you

Steve Williams
VFP9, SP2, Windows 10

RE: Print control in foxypreviewer

I always wonder why people use their own preview window. With the report engine replacement Foxypreviewr is, you actually suppress all the features it has in its own enhanced preview and only use half of it. At least that's my gut feeling, I haven't investigated it all.

The _Screen.oFoxyPreviewer object and all its properties are influencing foxypreviewers own preview window. And that's started by simply using the PREVIEW clause of REPORT FORM command. No more, no less.

Chriss

RE: Print control in foxypreviewer

(OP)
Hello
Mike, i have a New problem with this code

CODE -->

loPreview loPreview = NULL 
DO (_REPORTPREVIEW) WITH loPreview loPreview.AllowPrintFromPreview = .F. 
&& This is the important bit 

loPreview.AllowPrintFromPreview = .F. loListener = CREATEOBJECT("ReportListener") loListener.PreviewContainer = loPreview lolistener.ListenerType = 1 
REPORT FORM MyReport OBJECT loListener 

Until I build my app it work just fine but after I built it win32 exe It give me this Errol

"LOPREVIEW is not an object"
It wont let me to generate report

RE: Print control in foxypreviewer

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:
  • _REPORTPREVIEW System Variable
  • Including Report Files for Distribution
Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

RE: Print control in foxypreviewer

Are you serious that your posted code works at all, no matter if compiled or running within the IDE?

This line is nonsensical:

CODE

loPreview loPreview = NULL 
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:

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

RE: Print control in foxypreviewer

(OP)
Chris, Mike,
I got it, thank you
I set The right path for _REPORTPREVIEW and seems to work all fine

Thank you

RE: Print control in foxypreviewer

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

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") Preview 

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.
https://files.engineering.com/getfile.aspx?folder=...

RE: Print control in foxypreviewer

Quote (Rhtt)

I set The right path for _REPORTPREVIEW and seems to work all fine

Good to hear, that you got that working.

But that detail should not be your concern at all because as you initially said:

Quote:

I am using foxypreviewer in my app

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.app 

To see this for yourself, how about trying this:

CODE

? _REPORTBUILDER
? _REPORTPREVIEW
? _REPORTOUTPUT
DO FoxyPreviewer.app
? _REPORTBUILDER
? _REPORTPREVIEW
? _REPORTOUTPUT 
The values previous to initializing the FoxyPreviewer report engine are the vfp9 report apps, after doing FoxyPreviewer.app, the _REPORTBUILDER stays as is, the _REPORTOUTPUT is set to the FoxyPreviewer.app and _REPORTOUTPUT is set to a prg within FoxyPreviewer called PR_FRXOUTPUT. You only do DO FoxyPreviewer.app and it sets the system variables as it needs them.

I 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

RE: Print control in foxypreviewer

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: DO FoxyPreviewer.APP

3. When you are ready to preview a report, do this: REPORT FORM MyReport.FRX PREVIEW 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: _Screen.oFoxyPreviewer.lShowPrintBtn = .F. (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: _Screen.oFoxyPreviewer.lSaveAsPDF = .F.

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

RE: Print control in foxypreviewer

Mike,

Quote (Mike Lewis)

you have been given a lot of advice - perhaps too much advice

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.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login


Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close