[Please reference this post if you have not previously read about VFP-TMM.]
I’m trying to whip through these early FX subsystem related posts as quickly as I can. As we ramp up on the Life Change stuff I’m not going to be able to put much time into this project at all. And that part is going to happen pretty definitely and pretty darn soon.
So here’s today’s crop:
- FRX Device Helper Foundation Class. FRXDeviceHelper didn’t get changed as much as FRXCursor, but it did get two new methods to round out its abilities and help you deal with the vagaries of printsetups in ways that proved to be extremely helpful for writers of extension output.
- User Feedback Foundation Class, aka UpdateListener. You may be surprised that I thought it was worth doing this one, but in fact we back-ported all the good changes to fxTherm to UpdateListener. It’s perfectly okay to use it for its original purposes, when you don’t need the capabilities of the FX subsystem.
- FX User Feedback Implementation, aka FXTherm. I’ll just repeat what I’ve written in the FXListener docoid in reference to this class, to show you why I think this one’s important:
The Feedback FX object, fxTherm, provides the means for FXListener to take over the responsibilities of UpdateListener for user feedback during report processing. FxTherm’s code is almost entirely extracted from UpdateListener’s code (as emended and improved for SP1 and SP2). Its development served as proof of concept that almost any type of report decoration, even one innately tied to many reporting events, as UpdateListener’s display is, could be easily ported into an FX or GFX object rather than handled directly in a reportlistener-derived class. It also serves to show how an object derived from any baseclass (in this case, a form) can implement the FX API and participate in the FX reporting subsystem.
- GFX Rotation Implementation, aka GFXRotate. Man, this one was easy <g>.
Enjoy!