>>Are you saying that READ EVENTS do contains OUT OF MEMORY problems if too many windows are opened but Foundation Read won't? Are there any work around (I don't think by limiting the number of windows open is a solution.).
>
>I never put some code to check that in my framework.
>
>I guess the same goes with Word and other applications. The user can open as many documents as he wants but might end up with "Insufficient memory" after the 25th documents. :)
>
>The foundation read contains its disavantages as well. One is that it will make your application run and look slower because when the ghost form is on the screen, the user has the impression that clicking on it will give access to the form immediately but has to wait because the setup code will reload again, etc.
>
>I don't know any programmer using this technique in Visual FoxPro. We requested that for years and Microsoft did it in Visual FoxPro by putting the READ EVENTS.
>
>The power of READ EVENTS and a foundation read is certainly not the same.

In fact one of the key steps in converting an app from 2.6 to 3.0-5.0 is taking advantage of the foundation read. If you do MS convert program and don't choose the Visual option in the convert, it creates modal pageframes that have the look and feel of the foundation read even though they are read events.

To really convert an app from 2.6 to 3.0-5.0 you need to redo the forms with the event model in mind at every step.

This means moving code from the form to the object. Focus on the click, valid, activate, load, init, gotfocus, and destroy events. If you learn these and can use them well, that will account for most of your code.

The key is as Michel said, users demand flexiblity and want to be able to do tasks in an nonlinear order. Pull a form up, in the middle jump to another, then back etc. In Foundation read and in the modal read events, you just can't do this.