>>My modal forms are fully modal so I don't have menus in them. I can't help much more with getting menus to work in a modal form.
>
>so how do you cope with similar scenarios? ferinstance...
>
>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...
>

As long as the forms aren't modal, why is this a problem? And if the form is modal, why do you need to do something that's reliant on a menu point - your form should be able to fire object methods without resorting to the menu!

Dinner with my brother's kids explains this. A single-instance form (you can have chicken, smushed potatoes and lima beans all on your plate at one time, but only one pile of each) is not the same as a modal form (you can't have a cookie until your finish your lima beans.)

I'm probably going to get a serious reaming on this, but the idea of a modal form is that it's modal, self-contained, and it's behavior is similar to the nature of a transaction - once you start it, you finish or cancel it before going somewhere else...

To use a dialog approach to things, modal forms should implement "Abort, Retry, Ignore", not "Abort, Retry, Ignore, I haven't decided - I'll tell you Later"

>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?
>

'MyName' disappears in at least two ways. One is that you destroy the object, and all references to it in all contexts. It ceases to be. It is an exc-parrot in proper Phyton terminology.

The other is you hide it from vision; while it exists, you can't see it because you don't know how to point at it. You have a bank (your application) with three rooms (forms). Each room has customers in it. You enter the bank, walk into a room, pull out a gun and can point to any customer in the room and say "Give me your lupins!"; you can't see the customers in the other rooms, so you can't point to them in this context and demand their lupins at the moment. If you walk into some other room, you can point to those customers, but can't point to the ones in the first room unless you've still got a way to reference them. They ceased to exist from your present perspective.

>>You can always work through the _screen.Forms() collection to get a reference to any form that exists. Although I prefer to use my own form manager to do this for me.
>
>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?
>

The problem is expanding _screen in the Locals window, but there's a neat trick here. In the top of your code, for debugging purposes, do the following:

PRIVATE poScreenRef
poScreenRef = _SCREEN

This gives you a private object ref that points at the _SCREEN object, which is special in and of itself. Now, to look at the _SCREEN, use the reference poScreen in the debugger, and you can decompose and examine the _SCREEN object indirectly and watch it's behavior. For all intents and purposes, poScreen is the same as _SCREEN, because they both point at the same object.

The should be a (+) next to poScreenRef tro let you expand the object. One of things exposed is .Forms, which has a (+) next to it, and expand that and voila.

If you aren't anal about things, you could've made poScreenRef PUBLIC...