snip..

>He just uses modal forms. He doesn't have a startup prg but rather a login form is set as the calling form in the project.

We only set Form to modal windowtype if intended for dialog purposes. IMHO, READ EVENTS is the key to a TRUE-Windows based application, otherwise, the app is just sitting in Windows OS.

>
>>Kevin,
>>
>>I'm certainly in favor of READ EVENTS. You need some way to generate a wait state in your application. Other than starting a modal form, I'm not sure of another practical way to do this. I don't think I've run across a VFP programmer who doesn't use it. What alternative does your colleague use?
>>
>>>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?