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

hmm. Just tried that. Didn't work. The menus remained stubbornly unavailable.

suggestions?

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

yes, I can see the possibilities.

>
>
>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 the only problem with that is that during the handling of the modal form, we may still legitimately require access to other parts of the application through the menu system. I can see that your 'Push Menu/ Pop Menu' fix should do the trick - as soon as I can get it to work!


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

ah - now that clarifies things...

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

I like to think I understood this behaviour...


>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 the problem I have with this is not understanding quite how and when the form property reference you suggested will itself go in and out of scope...

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

and there is presumably a simple and sensible logic to when that scope is in effect. I just haven't grasped whatever that is yet!

>

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


I understand the distinction. The remaining question in my head is whether there is any other way to reference the object other than via the memvar. If not, - and the memvar goes out of scope while the object still exists - how can you do anything further with the object?

Thanks - by the way - this is illuminating stuff!

Harry