Harry,
I put my replies in sequence with your points.
>I'm in the 'cashbook'. I have a question on a credit note. I hop into the invoice form (hiding but not closing the cashbook because I'll be wanting to carry on where I left off as soon as I've sorted out my question) where I find that the problem relates to the original order so I now hop into the order form (leaving the invoice form similarly hidden but open) . Here I find that I now have to create a query for a bunch of related orders (or carry out some other function which is triggered from my system menu rather than the current form). etc etc
>
>All of which was a piece of cake in FP DOS but feels like pulling teeth in VFP...
"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.
Give every form a private data session. 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.
>I think I've finally grasped that - but just how do you "force has the same scope as the object itself."?
Variables are either private, local, or public in scope. They are private by default. Private and local variable go out of scope when the routine that created them ends, publics outlast their creator. Locals are only visible to the routine that created them, while private are visible to the creator and routines called from the creator.
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.
>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.
>tried doing this in the debugger just to get a feel for what the 'collection' looks like. Not posseebull - Apparently. So how does one see inside the forms() collection?
FOR Each oForm in _screen.forms
IF oForm.Name = "Inoice"
ENDIF
ENDFOR
