Well, unfortunately I just found a fly in the ointment. I have been through this before. I guess I just forgot about it. Here is the problem with using model forms for all aspects of the system ...

I do not wish to have the _SCREEN be a part of the system and I have no way of getting rid of it (that I know of). I can't make it invisible. I can't size if to very small so it falls behind my forms and I cannot move it off the screen. None of these things work because my forms are only visible INSIDE the _SCREEN. If I try to make my forms TOP-LEVEL forms ... they become MODELESS and I need a READ EVENTS statement. If I put a read events statement into my system then I need a CLEAR EVENTS statement and I do not know where to put it.
I will keep trying ... but I could use some expert help on something.



>Don, can I have your users when you are done with them?
>
>>Actually, I have rarely (actually never) had an application that
>>used anything other than MODAL forms and have never had anyone
>>unhappy with that. Most of my clients like SIMPLE ... and so do I.
>>However, I have always used a READ EVENTS statement and an actual
>>menu but always used modal forms. If this works ... it will open
>>up another option for me for small (and maybe even big) applications.
>>
>>
>>
>>
>>>>I am considering using a form for my main menu of an application.
>>>>I have found that this works ...
>>>>
>>>>My main program contains a call to the mainmenu form ...
>>>>
>>>>as in ...
>>>>
>>>>* main.prg
>>>>do form mainmenu
>>>>return
>>>>
>>>>and my mainmenu form is MODAL with buttons on it calling other MODAL forms.
>>>>
>>>>It seems to work. Any reasons not to do this ?
>>>
>>>Don,
>>>If you application lends itself to this type of design, go for it. However, some users may not like not being able to do multiple things within your application at one time. However, like I said, if your application requires that they finish one task before starting another, it's great.