Form behavour different if launched from menu or click event?

I am having a strange problem where the behaviour of a form differs if a form is launched from a menu or from say the click event of a button. The form is top-level with a default data session.

I have a few variables that are assigned as control sources to some textbox controls. I am using the destroy event to perform some updates using theses variables. This allows the update to happen regardless if the user clicks the exit button on the form or the title bar.

The problem is that the form behaviour seems to vary depending on how the form is initially launched. From a menu the above works fine but from a the click event of a button the variables are not available in the destroy event

Does anyone know why the behaviour is not consistent

Visual FoxPro2

What do you mean by "variables" in this context Where are they declared What scope do they have

Normally, in a form, you work with form properties and variables local to the method you're in. It's generally bad form to address variables created outside the form.

Tamar

I have been doing some experimenting and what appears to happen is that scoping of memory variables that are bound to a control behave differently depending on if a form is launched from a menu or from the click event of a button. For instance I have a control whose control source is vinvoicenum, in the init event I initialize minvoicenum to 100. If I launch the form from a menu the memory variable is available from any method in the form. If I launch the form from the click event of a button the memory variable is only accessible in the init event where I assigned the value. The exception is if I then click into the textbox that has the memory variable control source then I can now once again see this memory variable from any method on the form. The form is modeless and has a default data session.

I should mention that this project involves porting a v2.6 application to visual foxpro. Hence memory variables are used extensively and the ability to retain the use of the memory variables would not only save time but cut down on the potential to introduce errors.

>> that scoping of memory variables that are bound to a control behave differently depending on if a form is launched from a menu or from the click event of a button

Not true. The reason is that if a control is bound to a variable that is not in scope, VFP auto-creates a PUBLIC variable for that control. So if you run the form and the controlsource is not in scope it gets created as PUBLIC and thereafter there are no problems.

If you initialize the variable in the INIT() then it will be out of scope after the INIT() finishes.

Best advice is don't use variables as control sources. Either make them properties of the form itslef (they are always in scope then) or bind to the underlying data directly.

Appreciate the reply and agree that the solution would be to create form properties. I still think the behaviour is different depending if a form is launched from a menu when compared to launching from say the click event of a button. Try creating a top level form that has a button and a menu. Create a second form called launch that has a textbox bound to a variable named test and a button. Have the tab order set so the button gets focus, in click event wait window test. In the init code test = "Hello". Compare what happens when you launch the form from the menu and the button making sure you do not access the textbox field bound to the variable. I believe you will find that when launched from the menu the variable will display the value of Hello... When launched from the form button the variable will not be found.

Stuart

>>Create a second form called launch that has a textbox bound to a variable named test and a button.

Sorry this is something that I really don't have either the time or interest to mess around with. You may well be right and there really is a bug in the behavior when a form is called differently (though why it should matter is beyond my abilitiy to explain - code is code is code and does not behave differently when called from one place or another).

The solution, as stated, is don't do it that way! Your choice....