>Hi Ed, Using your idea to search the appname.LST file,
>
>Question1:
>I found the related routines in the c:\Microsoft Visual Studio\vfp98\ffc\_reports.vcx
>I presume this folder refers to FoxproFrameworkC...(?) and gets incorporated during Build.
>
That's actually the FoxPro Foundation Classes, which are used as the basis for much of the frameowrk.
> _output (object)
> _printreport (procedure) code has:
>
> CASE THIS.cOption == "GRAPHICAL"
> *this is the preview part...
> ZOOM WINDOW (lcName) MAX
> REPORT FORM (THIS.cReport) PREVIEW &lcClauses
> *and later to print...
> THIS.cTextFile = lcFile
> IF ".LBX" $ UPPER(THIS.cReport)
> LABEL FORM (THIS.cReport) &lcClauses &lcDestination NOCONSOLE
> ELSE
> REPORT FORM (THIS.cReport) &lcClauses &lcDestination NOCONSOLE
> ENDIF
>
>?? (Here's the question )
>-So it looks like maybe I could edit this to catch my summary Y/N?
>
> IF nOption = 1 && Summary
> REPORT FORM (THIS.cReport) SUMMARY PREVIEW &lcClauses
> ELSE
> REPORT FORM (THIS.cReport) PREVIEW &lcClauses
> ENDIF
>
Yep - but you need to ensure that the variable remains in scope - you may want to add it as a property to the class or form you're woirking with so that it doesn't get 'lost in the sauce'.
>Question2:
>The Framework generated Menu's File - "Print Reports" calls APP_GLOBAL.DoTableOutput()
>
>?? (Here's the question)
>-How do I get to this?
>
Somewhere in the initial program, there's a PUBLIC object being created named APP_GLOBAL, which serves as an application manager. Look for a CREATEOBJ() or NEWOBJECT() somewhere in the main of the application that creates the application object, maybe a line that reads:
APP_GLOBAL = NEWOBJECT('MyAppClass') && maybe with a bunch of parameters
The menu then invokes the method of the application object. If you change the class that the application object uses to have your new behavior in it, it should take care of itself from there on. The change you're making is to the class in report - making the necessary changes there should automatically ripple back through the system - that's part of the whole idea of OOP. if you add this summary behavior to the class once and it works, anytime you use this class again in the future the added behavior will be present. IOW, make it work the way you want it to once, and it's there for you to reuse down the line.
>(You don't use the VFP 6.0 Framework? Maybe I'll start a new question about that.)
>
I use a framework based on a pre-VFP6 framework called Visual MaxFrame Professional, which I've been using and adapting to my own needs for a number of years now. Since it works the way I want it to now, and I understand the framework well, there's no incentive for me to go back and use the framework that comes with VFP6, especially since I don't rely on the VFP App Wizards. There are a number of commercial frameworks avaialble; at least one, CodeBook for Mere Mortals, has its own support here on UT.
There are lots of third-party tools available for VFP - one I can't begin to give enough credit to is Stonefield Database Toolkit. It provides a set of extensions to the database container, and provides strong mechanisms for maintaining and updating data models and databases out in the field. In my case, it's paid for itself
MANY times over. SDT integrates very easily into the VMP framework which I use, too. I don't know what, if any, provisions have been made to integrate SDT into the VFP framework, but Stonefield has their support here on UT, and I'm sure Doug Hennig could tell you what's been done with it. Its ability to create VFP databases and tables, as well as providing basic, reliable replacements for some dangerous commands like REINDEX and PACK, a mechanism to roll out changes to tables, views, indexes and other aspects of a VFP database, and do many of the simple repairs that are routinely needed will more than pay for the product...
