Neither VB nor Delphi had a DOS version ... and without the internal Windows message dispatching process, DOS FoxPro needed something: it's own "message loop"; ie. READ GETS.

READ EVENTS (I assume) follows on the same concept as READ GETS in order to provide an easier migration path all the way up the line.

Also, VB and Delphi have usually at least one (custom) "main window" which accepts "Windows messages".

FoxPro also has a "main Window" (the "default" FoxPro window ... which accepts Windows messages) but you can't really customize it, so you need "procedural code" to get your application off the ground ... and in order to get that procedural code to "wait" for events at some point, you need an event loop (eg. READ EVENTS) or a modal Form.

All it might take to get rid of READ EVENTS is for the Fox team to create a _SCREEN.Init event that you could customize and to allow the Main FoxPro Window to NOT automatically release when there is no READ EVENTS (when running an EXE).

Otherwise, you don't really need READ EVENTS if all you want to do is run some sort of "batch" type process.

>You know, I've often wondered about the 'Read Events' clause myself over the years. Is there ever a time when processing is not desired? Why doesn't VB need it? I realise it's been like this forever, but I never really understood why an event driven language, which VFP purports to be, needs this. Why isn't it simply automatic like it is in VB. Afer all, is there a situation when one wants to write programs using only modal forms, or to have the form simply flash on the screen momentarily before the program ends? To put it another way, how many programs have you written without 'Read Events'. Personally I can't recall ever having done it.
>
>To the best of my recollection, it was never required in Delphi either.