>I've been having a 'discussion' with another programmer and we seem to have a disagreement concerning READ EVENTS (programmers disagreeing? Impossible you say?) He is of the mind that the READ EVENTS is an unecessary command and that it is really 2.6 thinking not OOP. Everything I have read seems to indicate otherwise. In fact if my understanding of READ EVENTS is correct, it is a integral part of OOP and is NECESSARY if you want to use things like toolbars and menus (neither of which his app contains). It also seems to negate the cumbersome task of halting your program with a dialog box or wait window if you call an outside app like MS Word (something else he has to do). I always use READ EVENTS in my apps and have not run across any reason NOT to use it. Anyway I'm just wondering if my thinking is correct or is his? Is READ EVENTS all it's hyped up to be? Also are there other things that READ EVENTS allows you to do that you could not otherwise do that I didn't mention here?

Kevin,

READ EVENTS is probably the single most misunderstood command in VFP. READ EVENTS has no counterpart in previous versions even though its name is similar.

READ EVENTS has one job, to turn control over to the internal VFP event handler and stop the execution of the routine that contains it. Execution will not continue until a CLEAR EVENTS is executed. For example, here is a system startup program;

* Startup program
* Save environment
* Set environment
* Open class libs and procedure files

* Create the application object

READ EVENTS

* Reset environment
RETURN

Whe this program is run it will do everything before the READ EVENTS. The environment will not be reset until something issues a CLEAR EVENTS.

Additional READ EVENTS will be ignored, there can only be one.

One of the reasons this command is so misunderstood is that it share its name with the 2.x READ command, however it is not related to that command at all. The READ command created a wait state, but it did not turn vontrol over to the internal event handler. If you wanted an event handler you had to write one and use the options (VALID, WHEN) of the read command to get at it.

READ EVENTS can be though of as "Ok, now let the user at it!".

There are situations where a read events is not desirable. Things like developer tools and apps that are designed to be called by other apps. For these types of apps a read events essentially renders them unusable for the purpose for which they were designed.

You collegue is incorrect, read events is not a hold over fomr the 2.x read command. I wish Microsoft had chosen a different for it, something like NowDoIt, LetTheUserAtIt, HandleIt, Start, WaitTillTheUserIsDone, or any other name that is more descriptive of what it is for.