SCATTER command not public anymore?

[ExtraD]

Hi,

i made severall programs in foxpro 2.6a and now i'm migrating to foxpro 8.
i'm creating a new program in 8 but when i use the scatter op in the load of the form i can't use the m.var in a page (tab control). aren't the m.var's anymore public? or is there another way?

thanx

 

[Mike Lewis]

The best way is not to use SCATTER at all, but to buffer your tables instead. That is much more in keeping with the VFP way of doing things.

If you don't want to go that far, use the NAME clause in SCATTER. This will create an object to hold the values. You can later GATHER from the same object. Then, create a custom form property to hold that object. The values will then be available throughout the life of the form.

Assuming you have a property called oScatter, your code will look something like this:

SCATTER NAME Thisform.oScatter BLANK

To access a value:

Thisform.oScatter.Cust_Name

To store the values back in the record:

GATHER NAME thisform.oScatter

Hope this helps.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[alvechurchdata]

Just to add to Mike's advice, each control on the form will be bound to a property of the oScatter object. The data source for the Customer Name textbox will be
Thisform.oScatter.Cust_Name.

The big advantage of this technique is that the oScatter object holding the data is part of the form and will vanish when the form closes. SCATTER MEMVAR used to cause all sorts of bugs because the variables persisted unless you took steps to dispose of them.

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[wgcs]

My understanding is that SCATTER MEMVAR always has, and still does, create PRIVATE variables, not PUBLICs.

In Foxpro DOS, we usually would SCATTER MEMVAR, then create a form using @ GETs, and finally issue READ, and the variables would still be in scope because the routine doesn't exit during READ.

Now in VFP, however, forms are often non-modal, and so the form appears, then the calling routine exits, and all the var's created by SCATTER MEMVAR go away, and the form crashes because its controlsource's are now missing.

One solution would be to always use Modal forms, but this severely restricts VFPs flexibility.

- Bill

Get the best answers to your questions -- See FAQ481-4875.

 

[Mike Lewis]

I fully agree with what Geoff and Bill have added, but I would repeat that the best approach is to use buffered tables. This is much simpler than SCATTER / GATHER, although I admit that it is an effort if you are migrating old 2.x code.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My sites:
Visual FoxPro (www.ml-consult.demon.co.uk)
Crystal Reports (www.ml-crystal.com)

 

[ExtraD]

Thanx for the options. Now comes the hard part in migrating applying the best working solution

 

[ChrisCarroll]

SCATTER hasn't changed at all.

The migration issue from 2.6 to VFP is: In 2.6, variables declared or scattered private in a Form's init become declared at the top of the generated .SPR file. The rest of the form is coded inside that same .SPR file and hence the variables are all in scope.

With VFP, once the Form.Load or Form.Init has finished, any variables declared go out of scope and vanish. The rest of the form doesn't see them.
Very confusing to the person just migrating from 2.6.
The quick and dirty workaround was what the migrator did - create an .SPR file to call the form, and have variables declared there.

Apologies for the historical pedantry ;-)