SET TALK appears to be on when running reports with SP2

I've been using VFP 9 SP2 ever since it first came out which was a long time ago. Yeah, I know there was that nasty Data Group bug, but to me, the enhancements in SP2 far outweighed the negative. Now that Microsoft has released a hotfix for the Data Group bug, I'm hoping more developers jump on the bandwagon and start adopting SP2. That said, a colleague reminded me last night about a bug where text is echoed to the screen as if a mysterious SET TALK ON had been issued.

This is a bug, but it’s one that you can easily fix yourself. You see, some of the new enhancements in SP2 were not implemented in the core VFP exe. They were implemented with a creative use of several Report Listener subclasses that reside in the FFC directory. When you run reports with SP2, the default behavior is to utilize these Report Listeners instead of the base VFP Report Listener class. The bug exists in one of those classes so you can change it yourself.

Modify the fxListener class of the _ReportListener class library and change the code in the LoadReport method. Simply move This.setFRXDataSessionEnvironment() so it comes before This.createHelperObjects() and the problem is solved.  

If you’re running on Vista, however, you have to be aware of the Virtual Store and work around it. When you edit the fxListener class, Vista makes a copy of the _ReportListener class library in the Virtual Store and your modifications are actually saved there and not in the C:\Program Files\Microsoft Visual FoxPro 9\FFC directory as you expected. Because a Virtual Store is specific to each user, it means the change you just made only works for the login you’re currently using. As soon as you switch to another login, the changes don’t exist for that user. To permanently fix the bug, move the _ReportListener class library from your Virtual Store back to the C:\Program Files\Microsoft Visual FoxPro 9\FFC directory, overwriting the original. Also, be sure to delete the _ReportListener class library from the Virtual Store for all users. If you forget this step, those users could be accessing an old copy of the class library.

Workaround: Gap with Multiple Data Groups

In November, 2007, I reported a bug in the VFP 9 Report Writer that related to data groups (Bug 312572). This isn't the major data grouping bug that everyone's been talking about, but rather a smaller one I stumbled on while doing all my testing. It has to do with a strange gap of whitespace appearing on the report under certain circumstances as shown in the following:



After getting some insight from a developer at Microsoft, I was able to understand what was going on behind the scenes. That knowledge helped me figure out a workaround for this issue.

The report has three data groups. The first data group breaks on an expression of: .T. The second data group breaks on a field in the data: GrpField. The third group is used to print some whitespace every 5 detail records. Its expression is: INT(rnLine / 5). The report also has a variable defined to help count the number of detail lines: Name = rnLine, Value to store = 0, Initial Value = 0, Reset value = GrpField, Calculation = Count.

The problem is that the third data group uses the rnLine report variable which is reset on the second data group. As the second data resets, it alters the value of the report variable, which messes with the data grouping and completely confuses the Report Writer.

The solution is to alter the report variable in a slightly different way so it doesn't confuse the data grouping. Only two slight changes are required, but the changes are enough to make the Report Writer happy. First, change the definition of the report variable to reset at the end of the report instead of the second data group.

The second change is to add the following to the On Entry Expression in the Data Group Header of the second Data Group: _VFP.SetVar('rnLine', rnLine - MOD(rnLine,5)). This change manipulates the report variable by reducing the value back to the last number that triggered a break. It's a sneaky workaround that's pretty effective as shown in the following example that doesn't have the gap:



As with most of the Visual FoxPro Report Writer, a little creative thinking can go a long way!

Workaround: Dangling Datasession Left After Running Report

In December, 2007, I posted about a bug in VFP 9 that causes a dangling datasession after running a report from form with a private datasession and using report listeners chained together as successors. Microsoft still hasn't fixed the problem, but I now have a workaround for the bug.

First of all ... I have to give credit where credit is due. I didn't come up with the solution. It was given to me by Rick Hawkins ... so thanks Rick!! But now that I have the solution, I want to share it with everyone who follows my blog (all three of you.)

The solution is actually quite simple ... just before you instantiate any report listener object, switch to datasession 1, instantiate the object, then switch back to the previous datasession.

LOCAL lnDataSession, loListener, loListener2

lnDataSession = SET('DataSession')
SET DATASESSION TO 1
loListener = CREATEOBJECT('ReportListener')
loListener.ListenerType = 1
loListener2 = CREATEOBJECT('ReportListener')
loListener.Successor = m.loListener2
SET DATASESSION TO (m.lnDatSession)

REPORT FORM Whatever OBJECT m.loListener


I'd rather Microsoft fix the bug, but I guess a workaround is the next best thing!

Gotcha: Workaround for Data Group bug

I've had a few people ask for suggestions on how to work around the ugly data group bug that I previously blogged about. So far, the only work around I have is not generic and has to be applied to EVERY report that uses data groups. I HATE this solution, but it's the only one I have so far.

1. Create a report variable for any data you need to show in the Data Group Header. Set the expression to the data field. (rcCustomer)

2. Create a report variable to count the number of detail lines in the data group. Set the value to 0, Reset it on the data group, and set the Calculation to Count. (rnCustCount)

3. In the Data Group Footer, force the counter to zero after the data group by entering the following in the On Exit Expression: _VFP.SetVar('rnCustCount', 0)

4. In the field object in the Data Group header, enter the following in the Print When expression: rnCustCount = 0

5. Now copy the field object, but change the reference to the data field to refer to your report variable (rcCustomer). Then change the Print When to rnCustCount > 0. Just stack this on top of the original field object.

You now have two objects in the data group header. The original one prints only the first time the data group prints. The second one prints on subsequent pages and uses the report variable instead of the data reference so it will be the right record. An added bonus to this solution is that you can add the word "Continued" in the expression that prints on subsequent pages.