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.

Installing VFP 9 SP2

Now that Microsoft has related the HotFix for the Report Data Group bug (read about it here), developers who have been holding off are now upgrading to VFP 9 SP2. This is great and I'm glad to see it. However, I'd like to take the time to remind everyone about some "gotchas" that might happen if you don't follow the right procedure when upgrading. 

If you have VFP 9 SP1 installed on your machine, there's a problem with the installation when upgrading from SP1 to SP2. It doesn't tell you there's a problem, but it doesn't fully install everything. The recommended procedure is to completely uninstall VFP 9 from your machine. Then re-install VFP 9, without any service packs. Once that step is completed, install Service Pack 2. Do NOT install SP1 .. skip that entirely. Just go straight to SP2. 

If you are running Vista, you also have to remember about the Virtual Store so as not to get bitten. Whenever you change a file in the Program Files directory, Vista creates a copy in your Virtual Store and redirects all future access to the new file. When Visual FoxPro opens a class, it does something that makes the O/S think it's been changed. Therefore, if you have ever opened any classes in VFP's FFC directory, those classes are now copied and sitting in your Virtual Store. That means when you upgrade to SP2, it installs new FFC files in the Program Files directory, but Vista keeps referring to the old ones in the Virtual Store whenever you access them. It completely ignores the new ones loaded with SP2. To get around this, delete the files from your Virtual Store ... HOWEVER ... if you have actually changed any of the FFC classes, you'll need to make copies of the files in the Virtual Store before deleting them so you can go back and compare your changes to the new SP2 versions and merge as needed.  

For those of you who want to install SP2 and still keep plain-Jane VFP 9 or VFP 9 SP1, that's not a problem. Rick Schummer wrote a great whitepaper that explains how to do this (Rick's whitepaper). 

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: Dangling Datasession Left After Running Report

If you run a report using a ReportListener from the FFC directory, and you're using a successor listener, and that report is run from a form with a private datasession, you end up with a dangling datasession after the report completes. If you keeping running reports in this manner, you keep building up more dangling datasessions. I don't think I have to tell you the consequences of a long day of running reports like this!

I posted this on Microsoft's Connect site so anyone who wants to confirm, vote, comment, etc. about this bug, the ID number is 316134.

Here are the steps to reproduce the problem:

1. Create a form
2. Set the datasession to private
3. Add a button with the following code in the click

lcReport = SYS(2015)

CREATE CURSOR junk (test I)
FOR ln = 1 TO 10
INSERT INTO Junk VALUES (ln)
ENDFOR

CREATE REPORT &lcReport FROM Junk

ThisForm.AddProperty('oListener', null)

SET CLASSLIB TO 'C:\Program Files\Microsoft Visual FoxPro
9\Ffc\_reportlistener'
ThisForm.oListener = CREATEOBJECT('_ReportLIstener')
ThisForm.olistener.listenertype = 1

THisForm.AddProperty('o2', null)
ThisForm.o2 = CREATEOBJECT('ReportListener')
ThisForm.oListener.Successor = ThisForm.o2

REPORT FORM &lcReport OBJECT ThisForm.olistener

4. Run the form
5. Click the button
6. Close the report
7. Close the form
8. Open the data session window
9. Notice an Unknown(#) session.

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.

Gotcha: VFP Reporting Bugs

I'm really frustrated that I have not received ANY response at all from Microsoft about the recent Data Group bugs I reported. I was already frustrated that they hadn't addressed any of my other report-related bugs .. but these ones are serious and were introduced by SP2.

In hopes of putting more pressure on them .. here's a list of all the bugs I have reported through the official channels. You can use the following link to go to the Microsoft Connect page. Near the bottom of the page is a place to enter the ID of the issue. Then you can rate the bug, validate it, and provide any additional comments. Maybe if enough of us complain, they will address it.

Microsoft Connect

249264 VFP Print When processing wrong parent record
291486 VFP Detail Footer Band -- Wrong record
292987 VFP Preview - Zoom level not always programmatically changeable
293615 Print When logic is evaluated at the wrong time in VFP Reports
295113 Shapes stretched across Detail Header and Detail Footer bands whacko
288896 Squished Printing
286313 VFP SYS(1037) no longer has a PRINTER button in Vista
286314 Report Properties dialog locks up
286552 Code References - error printing when not in Admin on Vista
286958 Drag control from Toolbox to Pageframe and Labels disappear
287927 Intellisense on SET gets confused
312568 SP2 broke data group headers repeated on subsequent pages
312572 Gap with multiple data groups on reports

Gotcha: More on the Data Group Bug

I've been trying to see if I can come up with a ReportListener that will somehow generically workaround the serious Data Group bug I previously blogged about (Data Group Bug) In the process, I tried to come up with a really good test report to make sure I'm doing it right. I created a report with 3 data groups so I can be sure my code handles multiple data groups.

Well .. let's just say I haven't even gotten to the part of writing code yet. While developing a test report, I came across ANOTHER bug related to data groups. What I'm seeing is a gap on the report after the 3rd data group header prints, but not every time. It only happens for the third data group, when it immediately follows the second data group header. Oh .. and it doesn't happen the first time for the set.

Figure 1 shows how the report looks on page 1, which is correct. Figure 2 shows what happens on subsequent pages, which is incorrect.


Figure 1 - The first page - without any gap.


Figure 2 - Subsequent pages - with a big gap!

Obviously, this whole data group issue is getting worse and worse. I'm afraid to keep working on the "workaround" code. Who knows what other bugs I'll uncover! I sure hope Microsoft fixes this! Maybe we should ALL flood them with emails about these report bugs!!

Gotcha: Serious report bug with Data Groups introduced in VFP 9 SP2

Here's the situation: You have a report with a data group such as Customer. You checked the "Reprint group header on each page" option to make sure the group header reprints whenever the details for the group overflow to a new page. You put some total information in the group footer band. The report looks somewhat like what is in Figure 1.

Figure 1: The "Good" report

Now let's say that the data just so happens to work out so that the last detail record for customer 1 prints at the bottom of the page, thus, the data group footer needs to go to the top of the next page to print.

In VFP 7, VFP 8, and VFP 9 SP1 ... you get what's shown in Figure 2. The data group footer for customer 1 prints at the top of the next page, without bothering to reprint the data group header information for customer 1. This is a bug .. but not exactly the end of the world. I could probably live with this anomaly .. if I really had to.

Figure 2: The "Bad" report in VFP 7, VFP 8, and VFP 9 SP1

However, in VFP 9 SP2, Microsoft attempted to fix the bug and inadvertently introduced a more severe bug as shown in Figure 3. The data group header prints at the top of the next page BUT it's printing the data from Customer 2, the NEXT record. Then it backs up and the data group footer prints for Customer 1. Then the detail records for Customer 2 begin printing WITHOUT printing the data group header for Customer 2.

Figure 3: The "Bad" report in VFP 9 SP2

As you can see, this is a real mess. Printing the group header with the WRONG customer information is far worse than omitting the group header. This is completely unacceptable in my opinion!! It's completely misleading to print Customer 2 and then show the totals for Customer 1. In fact, as far as I'm concerned, it could cause some serious legal issues for my clients using my reports in some situations.

As it stands now, you cannot ever safely print data in the Data Group Header band if it's marked to repeat on subsequent pages. This is a serious bug --- and Microsoft needs to fix this ASAP!!!

Gotcha: Not all Printers Rotate the Same Direction

This is the first post in a series I'm calling "Gotcha". This is where I plan to talk about bugs ... er, "features" ... that I've run across or other issues that have caused me grief. Hopefully, by letting you know about them, and some possible work arounds, it will you save you from many future headaches!

I’ve been writing reports for years and I recently stumbled across an issue that threw me for a loop. A report that was designed on my machine in Michigan wasn’t working the same in the Tennessee home office. After a lot of hair pulling, the light bulb went off and I realized what the problem was.

To print a landscape report, my printer rotates the text counter-clockwise; the printer in the Tennessee office rotates the text clockwise!

What? You’ve got to be kidding me. How can this be? I just ASSUMED that all printers rotate the same direction! Isn’t there a “standard” or something that all printer manufacturers follow? Well .. apparently not!

So why is this important to you? The answer is … Unprintable Margins.

Most printers have unprintable margins that you have to consider when writing reports. Typically, the right and left margins are the same, but the top and bottom margins may be different. Often times, the bottom margin is the largest margin. For example, my printer has .25” on the right and left margins, .07” on the top margin, and a very greedy .48” on the bottom margin. The key here is that these figures apply to a portrait report. When you print a landscape report, these margins are swapped … and the direction of the rotation determines whether the left margin becomes .07” and the right margin becomes .48” or visa-versa.

Are you starting to see the problem yet? I designed a landscape report that was tight on the left side and had a half an inch on the right side to accommodate my greedy “bottom” margin. When my coworkers in Tennessee printed the report on their printer, the entire left side was cut off. That’s because their left margin is now the greedy bottom margin. That means they can’t print tight to the left side like I can .. but they can print tight to the right side.

So now that you know about this dilemma .. what should you do about it? You can take one of two approaches. The first approach is to design the reports as “Printable Page”, make the landscape width no more than 10.25”, and let the printer decide where to place the text. The other option is to design the report as “Whole Page” and leave a generous .5” margin on both the right and left sides of the landscape report. Personally, I prefer the latter because I like to keep the report centered, but it means I lose a little bit of real estate. Of course, if you ever run across a printer that is even greedier than mine, you’ll have to change your report width accordingly.

Knowledge is everything! Hopefully this bit of knowledge will keep you from making the same assumption I did which caused me a lot of grief and aggravation!