Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Very basic form problem
Message
 
 
To
18/10/2003 12:04:11
General information
Forum:
Visual FoxPro
Category:
Forms & Form designer
Miscellaneous
Thread ID:
00840010
Message ID:
00840017
Views:
17
--------------
[Form1.Click event]

form2 = createobject("form2")
form2.show
---------------


So, you either have not declared this variable (in which case it is PRIVATE) or you've declared the variable and you don't show the declaration here (in which case it might be LOCAL or PRIVATE).

IOW, you have a scoping problem.

You are probably confused because when you have done DO FORM in the past (rather than a class) the variable reference is automatically declared PUBLIC.

You have a couple of choices you can make to solve your scoping issue.

1) Decide that the second form really should be modal (I'm not saying you should do this, just explaining that in this case there would be no problem -- because the scope of the reference would properly be inside the click event <s>)

2) Declare the variable PUBLIC -- bad idea IMHO. But emulates the "easy" way that DO FORM works.

3) Scope your reference properly by giving something, whether it is the calling form or an outside, controling object, the reference. Let's discuss the possibilities here.

If it is the calling form, then you say the following:

* Form1.Click

THIS.form2.Show()


IOW, Form1 has a member property and you attach the reference to this.

For starters, make sure that in Form1's release (or queryunload, or someplace well before its destroy) you properly release this reference for cleanup purposes so that Fox can close stuff up in a reasonable order.

Next, you realize that if they press the click button again, this reference is going to be pointing at the new form instance and the old one will go away.

This behavior *may* be what you want (if Form2 is supposed to be a singleton and you don't have any other work-in-progress in that form that won't be taken care of in Form2's release/destroy).

But suppose you want multiple form2 instances every time the user clicks. In that case you create a reference collection, not a single, simple member property as shown in the code line above.

You still do the cleanup when Form1 is about to close.

Now -- you've tied the instances of form2 to the "life" of form1. Suppose you want them to exist after form1 closes?

That's when you use an outside, or controller, object to manager your scope for these forms -- or, potentially, all the forms in your application.

You may want to look at my response in the thread marked "Problem closing modal forms in VFP wizard-based application". The application object in the framework manages modeless form references and gives them an "application scope".

The framework also supplies something called an "application mediator" object, which it knows may or may not be on all the forms in its collection. If a mediator object is on a form, the application can do some extra work for the forms. If it is not, the application still provides basic cleanup and data entry confirmation where work is in progress, for any form.

This type of approach is necessary when you are managing modeless forms in an application. It isn't enough just to say "I will invoke my form from a button" without thinking "how long will this form live?" <s>

Sorry, didn't mean to lecture you, but as you see you need to think through the behavior your want, and then your scoping decision will be easier to make <s>.

>L<
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform