Call a formset from another form

[foxuser20]

i used this to call any form
do form c:\folder\form.scx

and to pass a value:
form.text1.value= "value"

but since form.scx is a parent formset, im getting the error: "object form is not found."
in this line: form.text1.value= "value"

i think im missing something here..

 

[Scott24x7]

To run the form and pass it a value at the same time you need to issue something more like:

DO FORM C:\FOLDER\FORM.SCX WITH m.Memvar TO m.Returnval

That will pass a value back to m.Returnval on completion, if you need to do something with the result in your main form.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Mike Lewis]

As Scott has pointed out, there is a better way of passing a value between forms.

But, in any case, your code might fail because "form" is the name of the parent SCX file, but it's not necessarily an object reference to the formset. To get an object reference to a form or formset, you need to use the NAME clause in the DO FORM command. See the Help for details.

Now, having said all that, the question is: Why are you using a formset in the first place? Formsets were added to the language to provide backward compatibility to screen sets in older versions of VFP. As far as I know, they are almost never used nowadays.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Tore Bleken]

I want to give a warning! Hardly anyone with VFP some experience uses formsets anymore, they are a pain to work with and not recommended.

 

[Olaf Doschke]

In a formset you have a parent root object, so with an scx. To make things clearer let's assume you have an scx called myformset

Do form c:\folder\myformset.scx
myformset.form1.text1.value = "value"

So forms are the first layer of sub objects of a formset. Forms are to the formset, what controls (directly put onto the form) are to the forms.
You could have seen this yourself from the command window. Right after you DO FORM or click the ! tool and get DO ... echoed to the command window, if you type myformset. You get intellisense listing you the members of the formset, which don't contain the controls, but on the first level you have the form or forms.

How do you think a formset can have two forms and formset.text1 is available? You also can't skip the formset object. By having a form.scx formset your formset object is named form, but it's not a form, it's the formset. You confused yourself, so to say, by sloppy naming of things. If you design an SCX to be a formset, then make it easy for yourself, if not anybody else, and name it xyzformset.scx

There are sets of rules of good software development this breaks in the aspect of encapsulation:

An object should rather be self contained and responsible for itself. It can and should offer an interface for it's usage, ie all values it needs for it's initialisation should be passed to it, if the form can't itself know where to get them from. Otherwise an interface should offer methods like SetSomething and not just let others act on public sub objects from outside.
The way you do this, I assume there are even more lines acting on many other controls in the forms. This way you have two physical objects, the SCX file and this PRG or other code file, that only work in conjunction. You're causing a dependency that makes maintainance of this harder, eg if you later change the form and remove objects or add others, the code has to be adapted to.

"Easy, I know this", you say. Yes, you. Now. It's not natural. Each control can be set at design time in the form/formset designer via property sheet, for example. The default values are not constant? Fine, a form has a dataenvironment and can grab data, controls have a controlsource you can bind to data, too, also to variables and form properties. Tables and their fields are not the only possible controlsource types.

There's another thing specific to the way you can address a running form by its name: This only works as far as you set different names and there already is the discrepancy of scx file name and the name property. Every form typically is form1, like every grid initially is named grid1. If you run two SCXes in parallel, things already are different than you might think.

I just did DO FORM... twice, now please tell me, what you think about this:

Can you tell me, which form1 and form2 belongs to which formset? Also, the second formset is neither available as myformset2 nor myformset1, I still only have myformset available to address one of the formsets.

You better work with variables, that hold real object references and not this half baked name references. You have full control about the variable names and more important about their scope. DO FORM offers two ways of setting variables, both use the NAME clause, that doesn't set the form name, but puts the form object reference to a variable with that name, then you can decide to add LINKED to link that variable, which then means a twoway link of form and variable existence. The moment you set the variable=null or release it the form releases and vice versa: When closing the forms, the variable releases.

Besides having more control you also have more insight, eg the variable put into the watch window givesyou a handle to the form or formset and you can drill down, besides intellisense you can use in the command window. You throw aqway many advantages by addressing forms as that may have been the usual way 20 to 25 years ago. Object orientation is a good thing, even if you reject getting into programming that way, you can use the object nature of things at runtime at debugtime.

So after I do
[tt]DO FORM ... myformset.scx NAME fs1 LINKED
DO FORM ... myformset.scx NAME fs2 LINKED[/tt]

I have two real separate variables fs1 and fs2 and have control over both formsets. LINKED also makes the fs1 or fs2 variable vanish, once all forms are closed. Closing eg just fs1.Form1, fs1.Form2 is still available, and that also reflects in intellisense and in fs1.Formcount. The fs1.Form1 member vanished, which you can also check by PEMSTATUS.

You don't have to make the full switch to OOP to make use of the object orientation of VFP and not doing so you stand in your own way of getting things done easier.

Bye, Olaf.