A bug in the VFP Report Designer has always, ahem, bugged me: something seems to turn on the Printer Environment setting for a report. Unless you want a report to always use a certain printer, that setting should be off. Turning it on can make a report much slower to open (for example, if the printer saved with the report isn’t available on your system) and can cause other problems.
I don’t remember who discovered this (sorry) but the cause turned out to be clicking the font button in the Field or Label Properties dialogs, even if you then choose Cancel. But how would that affect the Printer Environment setting?
Tired of having to deal with this, I decided to track it down. Fortunately, the source code for the Report Designer dialogs is included with VFP (unzip HOME() + “TOOLS\XSource\XSource.ZIP” and look in the resulting VFPSource\ReportBuilder folder). After some digging, I found the culprit in the ChooseFont method of FRXFormatUtil (in FRXBuilder.VCX), which is called when you click the font button. That method checks whether the TAG memo field in the header record of the FRX is empty or not. If not, it uses SYS(1037, 3) to update TAG and TAG2 from the current printer environment (the code is actually in FRXCursor.PopPrintEnv, which ChooseFont calls). The idea is that if the report has a saved printer environment, that environment should be used since it may impact which fonts are available. However, here’s the bug: TAG may not be empty even when TAG2 (which contains the binary printer environment) is. I’ve seen a single CHR(8) in TAG when TAG2 is empty, which means there is no saved printer environment, but it passes the NOT EMPTY(TAG) check in ChooseFont so the printer environment of the report is overwritten.
The solution is simple: change the test in ChooseFont from IS NOT EMPTY(TAG) to IS NOT EMPTY(TAG2), then rebuild ReportBuilder.APP. I’ve already made this change in the upcoming Stonefield Query version 4.0.
7 comments:
Great job Doug!! I thought I was crazy with the Printer Environment reappearing on some reports. Now I know I'm not crazy (well .. at least not with regards to THIS issue!)
Good find, Doug.
Question though: since XSource is also now part of VFPX, why wouldn't you want the change in there as well?
(competitive advantage aside of course :) )
Cathy said it was a GREAT job. Nay, it was an INCREDIBLY FANTASTIC example of VFP "detective work". This is a VERY important discovery for those of us who spend a lot of time in report development mode. Thanks for solving this annoying issue!
Darn. My bad. Good catch.
Doug,
I found out why this was hapening a while ago on the Profox forum, but just never got around to finding out where! Well done, you saved me a job...now I can go flying instead!
Dave
Will do, Andrew.
Thanks so much Doug, extremely helpful! By the way, I found you pointing from http://blog.visionpace.com/2010/04/life-has-just-gotten-easier.html - SO glad I stumbled across it!
Post a Comment