This is a repository for known issues (and some solutions!) with the VFP Report Writer.
1. Device (Printer) Fonts aren't available for selection in Windows Vista and above. No known solution. Try using "Courier New" font has been suggested.
2. Printer Control codes (aka Escape Codes) can't be passed to Generic / Text Only printer if SET REPORTBEHAVIOR 90. No known solution. Workaround SET REPORTBEHAVIOR 80.
-- Darren Woodford
Title: RightClick method can fire with modal form and report preview open.
1) SET REPORTBEHAVIOR 80
2) Run a modeless form (Form A) that has code in the RightClick method.
3) Run a modal reporting form (Form B) that has a button to preview a report (either REPORT FORM x PREVIEW or REPORT FORM x TO PRINT PROMPT PREVIEW).
3) Click the reporting button so that the report preview opens.
4) If necessary, move the preview window so that Form A is visible.
5) Right-click on the background of Form A.
Observed: The RightClick method fires.
Expected: That it would not fire, because there's a modal form on top of it.
Comments: The easiest way to fix this is SET REPORTBEHAVIOR 90. If you can't do that, you need code in the form's RightClick method to check whether it should continue. The following code at the top of the RightClick code works for me:
oJunk = _Screen.ActiveForm
lBailOut = .T.
Vertical lines don't scale correctly if you have a detail band with a field marked as 'Remove line if blank' (unless, of course, this field is never blank).
Somewhere along the line, I learned that I could combine PREVIEW with TO PRINTER PROMPT so that the print button on the report preview toolbar would give me a print dialog. However, if I use the following syntax:
REPORT FORM NOCONSOLE PREVIEW TO PRINT PROMPT
I get a "Missing Comma (,)" error. This only happens if I am doing this in a PRG. If I have this same syntax in a VCX, it works fine. This is with VFP6SP5 -- Randy Jean
I don't run into any problems if I order the parameters in the following way (haven't specifically tested in a PRG however):
REPORT FORM NOCONSOLE TO PRINTER PROMPT PREVIEW
-- Brad Jones
Just ran into a relative of this one in an inherited application. Although I've used:
REPORT FORM PREVIEW TO PRINT PROMPT
many, many times, in this application, I get a "missing comma" error when I do that (even without Randy's NOCONSOLE). Moving PREVIEW to the end works. I'm assuming the variable is some setting, but I don't know what. --TamarGranor
If you change the printer from your own default printer, that printer is stored with the report and will try to use that printer, even after the app is deployed at a client site. USE the FRX and Clear the TAG and TAG2 fields to fix this problem. (VFP 9.0 provides new way to Page Setup while leaving unchecked Save Printer Environment. CR)
However, this may cause problems for landscape reports as the report will then use the default printer's current orientation setting for the report. An alternative for landscape reports is to use a printer setting that is commonly supported and rendered well, such as HP Laserjet (PCL 1).
Only if you clear the Orientation= line from the EXPR field. Clearing Tag and Tag2 should not affect orientation.
One solution may be to use Microsoft's ReportFormPrompt form as described in "How to set print options without a REPORT FORM ... PROMPT command" http://support.microsoft.com/kb/263287. And the download works as of 4/22/2008! -- Craig Roberts
VFP 9.0 (maybe SP2 too) extends and complicates report processing. http://msdn2.microsoft.com/en-us/library/zc487kf1(VS.80).aspx provides details about SYS(1037). Those of us with previous experience with the EXPR, TAG, and TAG2 files should note: "In previous versions of Visual FoxPro, saving printer settings in reports used three fields in the table's first record: the EXPR, TAG, and TAG2 fields. In Visual FoxPro 9.0, if you choose not to save Printer Environment with a report, much less information is stored in these fields, making it possible for your report to work more appropriately with a wider variety of printers."
I'm having Landscape "sticking" when I use "Report form .... to print" to the user's default printer and may opt for MS's ReportFormPrompt. Craig Roberts
I'm having a problem right now, where clearing the Tag and Tag 2 fields on a landscape report render it off the page abit. Portraits work fine. Is there any more info that could be added here? -- Mike Helland
It seems some printers/print drivers have a different amount of non-printable margins.
If you have a report with multiple columns that prints the columns across the page instead of down the page, and you have any data grouping, the first detail position of the report (i.e. the upper left position) will be blank, and the detail you'd expect to print in the upper left will print where the second detail position should print. To fix this, you must copy the objects in the detail band to the group header. Then, to prevent the first record from printing twice, you must double-click on the group header band and put a UDF call in the "On exit" field that simply calls a function that does a SKIP. (Thanks to Brad Schulz for solving this one for me.)
While this isn't a bug, it is something which bears watching, especially if you print on forms. Whenever a VFP report is printed, Windows renders it according to its current printer. Different printers have different page widths and lengths. This will make printing on forms inaccurate for any report unless you have the ability to control the types of printers used.
The height of a textobject affects the leading (space between lines.) It is not much of an issue for text that is being read by a human, but it has a severe impact on printing bar codes, especially PDF417. MS won't tell what the formula is (top secret, or they don't know) but I have come close. I have only tested on Arial, point size 4-12, heights 2000 - 20,000 ?FRU.
lnLeading = ( ( ( tnObjHeight + lnLineHeight * PhaseShift ) % lnLineHeight )- lnLineHeight * CenterShift ) * AmplitudeFactor
For details see Frx Leading.
HP 9000 printer: app uses combination of Word automation and frx to print batches of documents w/checks. Documents print in Word, then, collated between, checks print from frx. Frx is set up to print from tray 3 (where check stock is loaded) by keeping expr field populated, but clearing tag, tag2 - problem: this scenario worked for the past several years. User that performed this operation retired. New user signed on to domain: now, under this new login, intermittently will start printing checks to blank paper vs. tray 3. Nothing has changed except Windows user. Printer is on domain with it's own IP and uses HP jet direct so config/driver is exactly the same. If she logs in to Windows as user that retired, checks ALWAYS print to the correct tray. Frx & Word docs are being shared on the network. All permissions, etc. appear to be the same. This is very perplexing. Not sure where else to turn for help. We even had her try a different workstation. Same thing. Her login will not consistently print to correct tray, but the "old" user does. Her login may actually work for an entire day, then all of a sudden, blank paper again. Here is the expr field from the frx:
Obviously, DEFAULTSOURCE is the setting that specifies the input tray.
Environment: Windows 2000, VFP8 runtime, Office 2000 - anybody seen anything like this before? -- Randy Jean
Interesting, I googled and found a reference to this KB article: Q100603 Paper Pulled from Incorrect Tray on HP LaserJets, but alas, is no longer available. Anybody have a cache for this? -- Randy Jean
Apparently this is not just a tray issue. She also told me that the DUPLEX & ORIENTATION are being ignored after the first report is run. In other words, after printing one report, all subsequent output uses the printer defaults instead of what is stored in Expr field of the reports. -- Randy Jean
Problem solved. Got access to the workstation(s) having problems and created a new TCP/IP printer (instead of network printer, use local, tcp/ip, etc.) and installed the latest driver for this printer (However, I used PCL5 vs. PCL6). Everything has been working fine for a couple weeks now. May go ahead and install this driver at the print server, but didn't want to do this until I knew it was going to work.
Some VFP 9 Report Designer Issues
We have a widely-distributed application written in VFP 6, and we are planning to upgrade the platform to VFP 9 sometime this year. As a part of the upgrade we took a look at our reports and whether we might benefit from the new reporting features. In doing so we encountered some problems. This was using VFP9, SP2.
Issue #1: Altered rendering of the print image when using the Object-Assisted Report Engine
Upon switching the report engine behavior from 80 to 90, the field widths for various reports changed in such a way as to to truncate the display or to overflow data which fits fine using the "old" reporting behavior. For example, a capital letter "W" in a single character field was chopped off about half way. Longer character displays wrapped to a second line. This is using the default ReportOutput.APP. Upon resetting the behavior to 80, all was okay again.
This is because the VFP 9 reporting engine uses GDI+ to render the reports. There are subtle differences in how GDI+ renders text. There really isn't anything that can be done about this if you use the VFP 9 reporting engine. The only solution is to modify the report layout. -- Ken Dibble
Issue #2: Incorrect placement of centered text
This issue has existed for quite a while, but we were hoping that it would be fixed. Any centered label using a small font, such as Ariel 8, becomes increasingly skewed to the left as its length increases. This is most noticeable for centered labels where one is placed beneath another. In the Report Designer, everything is displayed at its proper location, but in the Preview window or on the printed page, the longer the string, the more off-center it is to the left. Larger fonts appear to be skewed also, but the offset is less compared to the width of the label.
Issue #3: Reverting Changes upon Preview
This one drove my programmer nuts, but we can't reproduce it consistently. This occurs when selecting Format and Font from the Report Menu after highlighting a label and then changing the font properties. Upon returning to the design screen, "deselecting" the label (which at this point shows the new font characteristics) and then right-clicking and selecting "Print Preview", the preview screen shows the label with "reverted" font chacteristics, i.e. those before the change was made. Furthermore, when closing the preview window, the font characteristics on the design screen also "reverted".
Very very slow work in report design mode. 20 seconds to save an expression box, over a minute to preview, loses landscape mode and probably other troublesome printer settings.
Click to change back to landscape and receive message "printer is not installed".
But printer shows as installed and "printing preferences" shows but not completely. Printer Properties also reports "Printer is not installed would you like to install it?"
And network area icon in "notification area" just busy busy busy when the delay occurs.
Solution: This is with a Dell 5200 workgroup printer - after it has an error, workstations getting these symptoms need to REBOOT. That fixes it. Craig Roberts
See also: Frx Tips Un Trappable Errors
Contributors: Barbara Peisch, Mikel Moore, Carl Karsten, Craig Roberts
Category VFP Troubleshooting Category Exam 70-155 Hot Topic
I also had problems changing printers. I needed to SAVE PRINTER ENVIRONMENT to keep the default landscape orientation. Using ReportFormPromt to change the printer removed the SAVE PRINTER ENVIRONMENT Checkmark. probably because it resets the TAG field to an empty string. I modified the ReportFormPromt in order to update the TAG field content. The previous OUTPUT, DEVICE and DRIVER properties are replaced with the new ones using the STRTRAN()function. It works great. ReportFormPromt.
( Topic last updated: 2014.06.13 04:41:57 PM )