>If the address form is run whilst another form is open, I think what is happening is that control returns to the calling form. I suspect this because the problem goes away if I make the address form 'modal'. Unfortunately this is not a usable fix as the user needs access to the usual menu items whilst in the address form and being modal blocks that.

The menu will be available if it has been launched from the address form's events. For example, in the address form (assuming it is modal) in its Init does a;

PUSH MENU _msysmenu
DO Main.mpr

Then the menu will be accessable from the modal form. In the Destroy you can;

POP MENU _msysmenu

to restore the original. You could even make a special menu for the Address form if you like.

>I have never quite grasped how to stop the code 'where I want it' in the event model. In other words, once I've opened the address form, I want the system - temporarily at least - to forget the existence of the calling form. I had thought that this would be accomplished simply by hiding the calling form on entry to the address form, but no such luck. The only way I can 'force' it is using modal forms but that is too limiting.

The correct way to do this is to make the form modal that requires it be completed before code continues. That is what a Modal form is, a form that the user must dispatch before anything else can continue. A non-modal form is an independent form that does not require the user's attention before other things can be done.

>And I still don't understand how, even if control is passed back to the calling form, given that the address object plainly does still exist, how vfp then fails to find it or any reference to it even though things like "wexist('ADDRESS') correctly returns .T.

Wexist() tells you about the existance of a window with a specific name, it does not tell you anything about objects like forms (which use a window to display themselves). So, wexist says "Yes, there is a window named Address" when you meant to ask "Is there an object that is referred to by the variable name Address?"

A given object can have more than one reference;

LOCAL loForm
PUBLIC loForm2
loForm = CreateObject("MyForm")
loForm2 = loForm
* Now both loForm and loForm2 refer to the same form object

Once that code ends loForm goes out of scope, that is the variable is destroyed. loForm2, because it is declared PUBLIC stays in scope. So in any other code outside of that snippet loForm will NOT reference the form any longer but loForm2 will.

The better way to control the scoping is to use object properties as I described in the last message. Why? Because PUBLIC variables are names to a location in memory that will stomp and trod all over every other routine, form, or anything else that uses variables.

I think a key to understanding this stuff is recognizing that there is a distinct difference between an object and a reference to that object. Both have a scope.

    loForm                       The Form Object
|------------|                |-------------------|
| MemVar     | =============> | Object            |
|------------|                |-------------------|

Note that loForm and the form object are in memory as independent items. The loForm memvar POINTS to the form object, they are not one and the same thing. The "Name" you are looking for is the reference to the object (loForm in the example) and not the object's name.