>
>As long as the forms aren't modal, why is this a problem?

you missed the first few chapters of this discussion!

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

I don't WANT modal forms. This is merely a bodge whilst trying to get round the problem which started the thread. My problem, in brief, is this:

Form A is active. I want to view a related record in detail using Form B. Form B is not a subform of Form A. It is an independent form in its own right.

So I run Form B and it duly appears with the record I want displayed. I can do anything I want to that record. However, lets say I'm bored with that record and want to add another record. Any changes I've made are duly saved (because the method that does this is native to the form class and not specific to the form).

The method which lets me add a new record, however, is specific to the form (because I need various checks made in that context which don't apply elsewhere). As soon as I run that method (formname.method) I get the error message that "object FORMNAME does not exist".

Jim patiently explained that I wasn't using a valid reference to the object. I tried his suggestion of running the form using the syntax "do form whatever Name myform" but this made no difference. And I didn't understand why it should have - as if I run the form with no others open, the problem doesn't appear.

I eventually twigged that because I'm running the form while another is active, even though I've hidden it, that the code is running the second form but somehow returning focus to the first form despite the fact that the second form is now active and happily displaying the desired record.

The only way I have so far found to stop the code leaving the second form before I'm done with it is to run that form modal.

But that prevents access to the menus which is equally untenable...

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

now that appears to conflict with what Jim just said. I quote:

"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. "

or am I misunderstanding what either of you are trying to say?

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

now that IS a neat trick!

Thanks

Harry