Folks, here are a couple of notes that should help you deal with VFP SP2 Beta issues… I hope…

Patching woes

We did not have an opportunity to test the VFP SP2 Beta patch files until after they went public. The patch files break a lot of FFC reportlistener stuff if you have previously patched to SP1, touched your FFC files in any way, or somehow managed to get the base files out of a state that the patch EXE recognizes as pure as the driven snow. 

We alerted MS about a day after the patch went live; we saw the problem(s) immediately. I don't know what the resolution will be regarding the patch mechanism, or when updates will be posted.

Meanwhile, the best thing to do is to make sure you patch against an RTM set of FFC files that you have never opened. (If you open a VCX, even just by Class-Browsing it, and without modifying anything the VCT file date stamp can get out of synch with the VCX date stamp. I have no idea why, but it really happens; try it!)

I don't know exactly which files will be affected on your system, but I'm positive about some of the reporting .H files not getting patched. If you use the FFC classes as-is, you won't see the problem, but the first time you recompile them you will see it. 

Why would you recompile the FFC classes?  Oh… I don't know… say, to include them in your application?

GFXNoRender: Why, and Why Not Quite Yet

Even if your files are totally in synch, you will experience problems with GFXNoRender if you build your FRXs into apps.  GFXNoRender is a multi-faceted little critter that exists partly to showcase a new and somewhat complex base product feature: the ability to change the name of the FRX to be run during the LoadReport event, and have the report engine respect that change.  This is extremely useful for people who want to preprocess the report tables before the run, but it's also quite dangerous. We wanted to have a little collection object showing some recommendations for its proper use, and we also built in some behavior to _ReportListener to make it possible for people to do this without tons of little collection objects all trying to grab the report and make changes to their own copy of it.  After all, only one FRX is going to run, you're not guaranteed of the order that the collections will "back out" the copies in UnloadReport, etc.

The changes to LoadReport occurred relatively late in our development cycle and we didn't quite nail our example object. If you want to use all the other great new SP2 extension behavior you get with FXListener, you can tell your listeners not to load GFXNotRender, in code like this:

* getting ready to preview:

DO (_REPORTOUTPUT) WITH 1

_oReportOutput["1"].gfxNoRenderClass = "" && that's all it takes to turn it off

… Other stuff such as rotation will work just fine.

So… is there any way you can use GFXNoRender now??

Please note that you should only see this issue if you are working with the SP2 beta build of the base product.  GFXNoRender works, by design, in either SP1 or SP2; it just doesn't invoke the exciting and dangerous new LoadReport behavior when used in SP1.  In SP1 mode, there is no preprocessing, so GFXNoRender treats a request to preprocess the same as the other flavor of NoRenderWhen. In other words, every time your NoRenderWhen (or NoRenderWhenPreprocess) expression returns .T., GFXNoRender just stops the Render event for that instance of the layout element. Not as performant as preprocessing, but even more dynamic.  When both work properly in SP2, you will use them each for different things.

So as long as you aren't try to deliver applications with a beta build of the product (now who would be foolhardy enough to do that?? <g>), you can use GFXNoRender to your hearts' content. And we'll get this one fixed up shortly — again, no word on the timetable, but it is truly fixable.

Important Backstory

My main concern here is for you to be aware that the partnership of collection objects and _ReportListener's ability to provide a "swap copy" of reports requires careful code, that we want to provide a model of it, and that you should expect it to work with built-in reports… within the limitations you always have when you work with built-in files and Xbase code.

What's that mean? You can't cross-call between APP/EXEs.  If you want an Xbase listener to "see" a built-in file, such as a JPG  or an FRX you want to swap-copy, you need to build that listener into the same APP/EXE as the file you want it to see.

This is not a new limitation, and it's certainly not report-specific. But it's going to be more and more significant with this LoadReport feature in play.  So I expect to see more of you building in your _ReportListener.VCX to your app, and getting friendly with it as a class library, rather than relying on _REPORTOUPUT as a separate app.

This is all to the good; the app was only there to transition you from SET("REPORTB") = 80 syntax while getting object-assisted report runs anyway. 

If you want to continue using the old syntax transparently, and you want all this stuff to work with built-in files, you can still do that.  Just set _REPORTOUTPUT to FRXOUTPUT.PRG rather than the separate app.  Instructions are in the docs.