>In addition, the Event Object included with the Mere Mortals framework is yet another abstraction that is used to encapsulate an application Event. Here is an example of an Event: The VFP application we created for the Pentagon manipulates PowerPoint slides. One of the things we do with the slides is upload them from a local VFP database to a remote Oracle database. We have an Event Object called "UploadToOracle" which acts as a supervisor of the Upload Event, handling communication and processing between three different business objects.
>
>Again, you don't *have* to create Event objects...you could just place the code in custom methods of forms or controls, but with a true object-oriented language like VFP at our disposal it's good to make use of its capabilites.
>
>It's also great for maintainance purposes to open up a project and know that all the major events in the application are encapsulated as objects and stored in the AEvents library and all the Business Objects are stored in the ABizness library.
>
>As with other OOP principles the Event object may be a bit of a strange concept at first, but once you grasp the concept you'll be creating events left and right!

Funny you should bring up Event Objects Kevin, my goal this week was to figure out where I can use Event Objects in the App I'm designing. So if you don't mind, I'm going to vent my thoughts and decision for your honored opinion ;)

Its a Data Warehousing type App with the sole purpose to generate like over 200 reports to both local printers in my office and remote printers across our network to offices throughout the country. Right now my FPW 2.6 version of this app is menu driven, user picks a report and a single program performs all the work for that report.

Work involved includes refreshing (zap & append) tables from comma delimited text files that are exported from a Unix System that does all the transaction processing, billing, and equipment configuration for pagers and cell phones. Once the tables are refreshed, then there is relational processing that needs done to make the data usueable, followed by report processing to create a cursor/table to drive the desired report.

With the guidance of a Mentor from ISResearch in Cinncinatti, this is what the the next generation of my App will do: One utility module to transfer text files from Unix box to my database server. One utility module to refresh the tables and do the standard relational processing. Then a VFP top level form (Report Generator App) to allow user to select desired report and printing options. Eventually this system will use SQL as its back-end to my VFP App, but for now I just need to concentrate on the Report Generator, which will handle the report processing on the fly.

My Mentor recommended I keep using *.prg's for my report processing code since that's what I'm used to... but I think I might go the route of a Class Library with many methods. He also suggested since the Update Utility module will run at night and drastically reduce the time involved to generate a report, that everytime a user selects a report to print that the report processing happens no matter what. Situation is though that we print a report with "fresh" data here at our office, check it, then remote print the same report to multiple offices. This means if a user doesnt efficiently select printing options on a report run, the same report processing code could be executed multiple times in one day. Solution - have the app check the date on the final report table (loose cursors) and prompt user whether or not to run processing code if the date is the same as current date. I thought this was a good case for an Event Object, but because of VFP newbie fright I decided to just handle this with a method and maybe change it later. Now after reading your input here about Event Objects, seems maybe my first instinct of using an Event Object to handle this was the better idea?

=D) Rox