Actually, DO FORM X NAME X LINKED can be different. Usually, though, you would declare a public variable in your app, say oThisForm. Then, when you issue DO FORM x NAME gcThisForm LINKED, you can reach form x anywhere in your app by reference to the variable. And you can release form x by issuing oThisForm = "" which removes the object reference.

Putting forms in on the fly as Ed does is interesting, reminiscent of what Lisa (Slater Nichols) does in her MasterClass framework. Having a public reference to a form can be useful where you always want to be able to get to a specific form for a particular reason.

Hank


so DO FORM myform and DO FORM myform NAME myform
>should be equivalent (somebody please tell me if they're not). I don't understand why, but even though _SCREEN.myform doesn't seem to help with scope, you can always do as we've been advised and loop through _SCREEN.Forms(x), for x = 1 to _SCREEN.Formcount, looking for _SCREEN.Forms(x).Name = yourformname, which is the name property of your form as seen in your form designer, and not the form object name.
>
>As soon as I formulate the question in my mind better, I plan on making a new thread in which I ask about the best OOP way to manipulate all the forms in my app. It probably has to do with keeping properties in the application object to keep track of them. DOing FORMs from other forms, tree style as I do, is different from ol' TASTRADE and can pile up forms in memory.