Doug Hennig - Windows PowerShell: Batch Files on Steroids

On last May 05 at VFF - Virtual Fox Fest - the new online VFP conference, Doug Hennig presented the amazing session Windows PowerShell: Batch Files on Steroids. The organizers of VFF were very kind offering a recorded version of all sessions for free for the community in YouTube.

This specific session dropped me completely, opening a whole new world of possibilities. As we can see in the video description: "Windows PowerShell has been included with the operating system since Windows 7 and is available for download for older systems. What is PowerShell? It's Microsoft's task automation scripting framework. PowerShell isn't just a replacement for batch files; it can do a lot more than batch files ever could. This session looks at PowerShell, including why you should start using it and how to create PowerShell scripts."

I just loved to know we can access almost the whole "Net Framework" using some batch files! I just started with some simple tests, and this looks really very promising, and will simplify several tasks.

Thanks very much for sharing!

XFRX vs FoxyPreviewer

I felt very honored to know that the VFP guru Rick Schummer presented a session - Visual FoxPro Reporting: XFRX vs. FoxyPreviewer in the 2022 version of VFF - Virtual Fox Fest. The organizers were very generous offering a recorded version of all sessions for free for the community in YouTube.

Rick very quickly and impartially shown some of the main features of both tools. 

Regarding FoxyPreviewer, I have some few considerations or remarks. Of course it would be impossible or Rick to know all the possibilities and features available. I just want to make clear that I feel very thankful for the review. And I am totally aware that the documentation needs some updates, and some points could be better explained, so here I take the opportunity to try to clarify some points.

• Exporting report to an image file - There are 3 available options:
  - OBJECT TYPE 16 - This is the object type related to exporting to image files. Works exactly the same as the others.
  - OBJECT TYPE 20 - This OBJECT TYPE was not discussed in the presentation. It will choose automatically the ReportListener needed to generate the desired output, according to the file extension passed in the TO FILE clause. The available types are: PDF, RTF, HTML, MHTML, GIF, TIFF, EMF, JPG or PNG.
  REPORT FORM YourReport TO FILE MyImageReport.JPG OBJECT TYPE 20
  - Using the FoxyListener.OutputPage method &&Like regular VFP9
• The truncated numeric fields in reports - He was very precise in his explanation, but I still would like to add some few information from a FAQ related to this:

When I run my reports with FoxyPreviewer sometimes asterisks symbols ********************* appear instead of the field. This was originally working, before using FoxyPreviewer

That happens because FoxyPreviewer uses the SET REPORTBEHAVIOR 90 mode, that uses GDI+ to render the texts. Unfortunately there is a slight difference of the size of the strings between these modes. To fix it, just edit your report and enlarge that field!

You can set the property - lExpandFields to make the report engine show the field numeric value ignoring the field size.
Using "lExpandFields", FoxyPreviewer retrieves the value that overflowed and resends it to the report engine with an enlarged field width.

This is a known issue, and Lisa Slater Nicholls wrote a short blog post regarding it:
Why do report layouts in VFP9 need wider field/expression controls than in VFP8 and earlier?

And here's another interesting text from Lisa, that explains the reason for that:

With REPORTBEHAVIOR=90, the new report engine uses GDI+ to render output, and text string rendering requires more space than plain old GDI.

The Report Designer uses GDI - not GDI+ - to render the report layout components, including all the text strings that you see. So if you visually right-align a label report element, the report designer records the leftmost co-ordinates of the element (the text start position) in the layout.

The length of the string under GDI+ rendering will most likely be greater than what you would think, based on what you see in the Designer.

• SET COMPATIBLE ON - Oh, this is a known issue, and I had it fixed before. I just don't know why the fix was not included in the last version. I hope to post an update very soon.
• ReportPreview.App and ReportOutput.App - As shown by Rick, these files are no longer needed if FoxyPreviewer was elected to be your single ReportEngine. I just feel important to add that if you are used to turn it off, you still need those files to restore the Reporting engine to the default VFP9.
• Excel bug / Enhancements - Please send me your files and I will be very happy and honored to aply your updates to the main distributable version!
• lOpenViewer property - In one of your samples Rick was using the property ".lOpenViewer = .T." - That means the generated output file would be opened automatically after generated. But the next REPORT FORM command contained the "TO FILE" and "PREVIEW" clauses. The "PREVIEW" clause means exactly the same - to open the file automatically!
  That's a very interesting usage of FoxyPreviewer. If you want your report to be shown in the default PDF viewer instead of a VFP FORM, just use the command:
  REPORT FORM YourReport OBJECT TYPE 20 TO FILE TempFile.pdf PREVIEW
• The "PrintingPreferences" - Rick told us he feels some kind of frustration with the fact that the report is closed after you change your report settings in that dialog. But that's exactly what the "PRINTER PROMPT" clause does! From that dialog you have the opportunity to change the printer, copies and other settings and call the printer directly.
• Rick was asked about embedding the toolbar in the Preview window. As he said, not in v2.99, but docking the toolbar is possible.
• David Acuña asked about determining the SMTP server values previously. Yes, that's possible. Just set the "cSMTPServer", "nSMTPPort" and other related properties previously, just after FoxyPreviewer was initialized.
• Maybe I misunderstood the real meaning of Rick's statement when he said that "The configurations are Global, not Per User". In fact, when you start FoxyPreviewer.App it will load the settings from the file "FoxyPreviewerSettings.dbf". This file is automatically generated after the 1st run of Foxy in that folder. Each of your users can have their own Settings Dbf file! You can save a copy of FoxyPreviewerSettings.DBF when your user logs off. Next time, after logging in and before calling FoxyPreviewer.App replace this file with the desired one. So, you can save a settins file for each of your users! When FoxyPreviewer does not find that DBF in its folder it will create a new one.
  
  
  Yes, everyone using that APP on that same machine will use those settings, as he mentioned.
  
  
  Here are some new thoughts regarding this, using a not very well documented possibility... There is an option to start FoxyPreviewer in a separate folder:
  
  
  Immediately after the user logs in your App, and the user is stored as "m.lcUser", people can try the following:
  
  
  lcFolder = ADDBS(JUSTPATH(SYS(16)))
  lcUserFolder = lcFolder + "Users\" + m.lcUser && Make sure the folder exists
  DO FOXYPREVIEWER.APP WITH (lcUserFolder)
  
  

  This way, every user will easily have his own Settings table. What do you think?

  
  
  
  
• Distributing FoxyPreviewer - People just need ONE SINGLE FILE - FoxyPreviewer.App. And there is no need to install it. Just a simple"DO FOXYPREVIEWER.APP" at the beginning of your EXE code and it's done! The recommended is to store it at the same folder of your EXE, and make sure that folder will allow Foxy to create a subfolder and save some custom configuration files.