Hi Jim

>"Piece of cake in 2.x", that depends on what the results really are. I wouldn't make any of those forms modal. I would limit communication between the forms to a pass set of parameters and allow each form to be totally independent from the others. I would leave the user in control of what they chose to do when.
>
exactly what I did in FPDOS and what I'm trying to do in vfp...

>Give every form a private data session.

hmm... got horribly confused with that approach when I tried it a few months back. But I can see how that would help. Where can I find an idiot guide to using Private data sessions?

> The user can be viewing the credit fomr and decide to look at an invoice. The only thing the invoice form would do is to position itself on the invoice requested, other than that it is a full featured Invoice form. The user could click back to the credit form or stay in the Invoice form or even call up the Order form if they like. The order form would do the same as the invoice form. When they finish it is the user's job to close the forms that they opened. I don't really see any of these forms as modal.

nor do I - don't forget modality only came up as an option because I found that running 'form2' while 'form1' was still active gave me the problem which inspired the title of this thread. I was unable to refer to anything on form 2 unless I made it modal.

>
>Whnever you create a reference to an object you are responsible for destroying it appropriately when necessary. My suggestion is this, if the Credit form needs a reference to a subform, then give the credit form a property to store that reference in.

the credit form does NOT need such a reference. I just need to be able to refer to form2's methods (or whatever) while form2 is on screen. I can't seem to do that unless I run it modal because the first form is still active.

>>I can see how you initialise the scope by using the syntax you've advised (do form blah name myname) but at what point does 'myname' disappear? If it automatically vanishes when the form is 'destroyed', no problem, but can anything cause it to go out of scope either prematurely or to remain in scope even when the form has been destroyed. If so, how do we control such behaviour?
>
>The reference will NOT automatically go out of scope on object destruction, as a matter of fact, the reference will prevent the object from being destroyed if it is still in scope. The sy=ntax I advised is to get to know what the reference variable name is. It is the worst possible way to do what you are trying to do. A much better way is to use a Form Manager that launches all forms for you and keeps track of them.

now I'm confused because that seems to conflict with what Ed Rauh has just said in his reply!

Harry