Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DO FORM MyForm is an Object sometimes, other times not

Status
Not open for further replies.

dantheinfoman

Programmer
May 5, 2015
131
US
Hi All,

When I run the line
Code:
DO FORM MYFORMTEST
within the startup.prg, it creates an object called MYFORMTEST. So
Code:
TYPE("MYFORMTEST") = "O"
appears to be True

However, when I don't use startup.prg, and just call the form from some button or top menu icon, using the same
Code:
DO FORM MYFORMTEST
it doesn't register as an object.

Thoughts?

Dan
 
Ok, so apparently I had to declare this as a public variable and anything opened in startup.prg becomes a public variable automatically unless stated otherwise.

Ugh!

Thanks

Dan
 
help about DO FORM said:
If you omit the NAME clause, Visual FoxPro creates an object type variable with the same name as the form or form set file.

The scope of this variable is typically private, as you don't declare it previous to DO FORM.
Private variables created in main.prg stay in scope as main.prg always is on the call stack.

Doing DO FORM in a button click the variable is released with the Click method finishing.
The Form is not linked to the variable (this would need the extra option keyword LINKED), so it does not release, but you have no variable with a reference to the form.

If you switched to classes, you'd do MYFORMTEST = CreateObject("myformtest") and would also see the form stay when doing so in main.prg and vanish, wehn calling from a command button.

We use form handlers to create forms, which also put a form reference into a global forms array or nowadays collection, that is better than creating public vars.

Bye, Olaf.
 
Yes, this is a basic variable scoping issue. With the exception of the addition of LOCAL variables, scoping remains unchanged since the earliest versions of Foxbase/dBase. What's changed is how we execute code.

If you execute code in a click method, you don't stay "in" the click method. It runs and when it's finished the variables created there go out of scope. (The exception is when you make a form modal, which pauses execution but then nothing else can happen.)
 
Hello dans!

Modal forms are an exception to stay in scope themselves, but their click events also end and private or local variables created in their events or methods are also released when these methods end.
Private variables you create in the init of a modal form also release, just the form itself keeps the call stack frozen on its call like the stack is frozen on a READ EVENTS line (as long as no event happens) and further code running is running in the next stack level.

The concept of PRIVATE variables is a bit complicated to understand. On the one side they behave like local variables from the point of view of the call stack level they arre created in, because they release when this call stack level ends. On the other side they behave like global variables on the inside, called code also can see them. That makes them something inbetween local and public. I think they once were invented as some kind of private properties before the OOP concept was added to the language. The idea is their scope is still limited, they only bleed in to further call levels, and since you know and control what you call this has some privacy to them, they release when code return to the calling code which is what controls you, is the outside and therefore again they are private and unseen by the outside from the perspective of calling something means it's inside and being called means that's the outside.

From the perspective of the main.prg every code is inside and so a variable created there is private to all code executed, which has the same effect as public for that special case. The outside is what called main.prg, and that is nothing, at least nothing VFP related (but the stub exe code starting the VFP runtime and starting execution with main.prg). You could anly say the outside is the OS starting the VFP EXE.

PUBLIC variables are also seen inside your whole code. The only difference of explicitly declaring PUBLIC variables is, they are not linked to the call stack level they are created in, even if you create them in code called from code called from main, they stay in scope until the EXE ends or you explicitly RELEASE them.

Bye, Olaf.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top