>>>>>>>>>>>>I need to get access to a object this is in a FORM that is not active.
>>>>>>>>>>>
>>>>>>>>>>>You can reference any form ("active" or "inactive", btw I don't know what you mean here), the only thing that this form must be loaded.
>>>>>>>>>>
>>>>>>>>>>If you have these FORMS loaded.
>>>>>>>>>>form1
>>>>>>>>>>form2
>>>>>>>>>>form3
>>>>>>>>>>and... you are in form1, but you want to access objects in form2 and form3,
>>>>>>>>>>what would the the code look like.. code sample please.
>>>>>>>>>
>>>>>>>>>Rob, it's the same code as you got from previous thread (about Form.Release).
>>>>>>>>
>>>>>>>>OK - so you are saying that I can
>>>>>>>>_SCREEN.anyform.RELEASE or
>>>>>>>>_SCREEN.anyform.grid1.visible=.t. or
>>>>>>>>_SCREEN.anyform.commandbutton.enabled=.f.
>>>>>>>>
>>>>>>>>provided I...
>>>>>>>>do form myform name anyform
>>>>>>>>
>>>>>>>>Is that right?
>>>>>>>The general gist of a lot of your questions lately seems to be that you want to manipulate forms and their objects from other forms, without putting them all in a formset, which is reasonable, but FoxPro doesn't seem to make it easy. I've been trying to do the same thing lately. In my case, I'm DOing FORMs from other forms, hiding the forms I came from, and then .Showing them again when I exit the second form, making a big form tree structure. It's easy when you have a simple app with no menu and no READ EVENTS: just make all the forms modal. You are probably finding, as I am, that these form object names seem to go out of scope when you are more than one form away, even though you used the NAME clause of DO FORM. To me, it looks like if you DO FORM form2 from form1, and DO FORM form3 from form2, you lose the object reference to form1 when you reach form3. Anyhow, the default form object name is supposed to be the name of the .scx, 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.
>>>>>>
>>>>>>When I started to look at Visual Fox two years ago, I formulated about the same questionnaire, see that it's too long and decided to use Formsets. I still use them, and believe me, they are very good and simple to handle (truly OO referenced). Actually, I use empty formset (containing toolbar only) and add forms (addobject from class) dynamically.
>>>>>Formsets would probably work fine for my tree structure. I'm using my usual excuse of modifying someone else's app as the reason why I didn't do that. Do you put every form in an app into one big formset? I guess that forms that never touch each other wouldn't share a formset, even by this logic. I'm thinking of the hypothetical case where you have a whole lot of forms, many of them nested, and multiple paths through the app.
>>>>
>>>>Hi Bret and thanks for your comments..
>>>>How do you use empty formset (containing toolbar only) and add forms (addobject from class) dynamically? Could you show me some code?
>>>>
>>>>>>>>>Do you put every form in an app into one big formset?
>>>>No - I look at life as a group a functions… If you can separate something and still make it work and it can be somewhat generic, than it should be a function. Why would I add a FORM to a FORMSET if it can stand alone and be call on when needed. End of story.
>>>>I would be willing to listen to other comments on this subject….thans..rob
>>>
>>>Using a formset simplifies the references. If you are in form3 and want to do something to form1, you can just say myformset.form1.stuff when you are in form3. The reason I suppose Ed suggests we instantiate forms in a formset with CREATEOBJECT(myformclass) is because if you load a formset with all its forms, they're all in memory at once when you don't need them all, and the whole formset takes longer to load. If your formset contains the toolbar and maybe the first form to be displayed, it loads faster. The button on form1 which I use to load form2 can say form2=CREATEOBJECT(form2class) and form2.Show, rather than DO FORM form2, as it does now. That button could either form1.hide, or it could RELEASE form1 and then CREATEOBJECT(form1class) again later, depending on whether I care more about speed or memory usage. If I have a formset with three simple forms, and I expect the users to go back and forth a lot, I might load 'em all and just show them and hide them. If the
>formset
>>>has 15 forms, and some of these have 15 page pageframes and a couple of grids, each with dozens of controls, and embedded pictures, and will be run on an old machine, each form might be better off being CREATEOBJECTed and RELEASEd as needed.
>>>
>>>I think people have other OOP reasons for CREATEOBJECTing everything, rather than just using their classes to put stuff into .SCX files, but I don't understand that part yet.
>>>
>>>I seem to have made a new verb: to createobject - I createobject, you createobject, he/she createobjects, we createobject, y'all createobject (for Texans) they createobject. :)
>>
>>Hi Bret - thank you for your comments.. I have not use CREATEOBJECT. After
>>reading you comments, I can see some of the value of CREATEOBJECT. Could
>>you give me some sample code of how to use CREATEOBJECT?
>>thanks..rob
>If your formset is a class, then where you would DO FORM myformset, you would instead say
>oFormset = CREATEOBJECT(myformsetclass)
>oFormset.Show
>
>In the init of your formset, you could show your form1, like so:
>THIS.AddObject(myformname1,myformclass1,anyparameter1)
>THIS.myformname1.show
>
>If you have a button on form1 that is supposed to show form2, then you could take out the DO FORM form2 and put in
>THISFORM.Hide
>THISFORMSET.AddObject(myformname2,myformclass2,anyparameter1)
>THISFORMSET.myformname2.Show
>and if form2 is modeless, you might be able to put THISFORM.Release here. Then you'd have to instantiate form1 again elsewhere.
>
>The details of where you show, hide, and release forms in your formset will depend on your structure and requirements. Code like this could be in your menu, or perhaps in some event handling method of your application object.

Bret, you touched another formset point here: Formset can contain custom methods , and, if you just DO FORM, _SCREEN (actually formset too) cannot have them. BTW, I use Thisformset.Addobject(...) (not CreateObject).