>Hi Tony,
>
>>So, even I have variables passed to the form is it better
>>to add properties and put the variables values on them?
>
>Definetely yes and no :-)
>
>Yes, when you don't want those passed variables to be seen outside the form.
>No, when you use a parameterobject, that's i.e. added to _screen like this:
>
>
>_screen.addobject([oParameters],[myParamObject])
>
>
>>Another question:
>>How to deal with the type of the values (string, numeric,
>>date, etc)?
>
>Where's the difference? For a property those are only values that get stored in it. Now it's a date, next time it will be an integer. VFP doesn't know strong typing, so the type of value is defined when you store it.
>
>I will give you an idea of working with parameters on a rather flexible basis.
>
>Create a cursor that contains all the values, that you need in your form. Next insert all the values into that cursor.
>
>
>CREATE CURSOR crsMyParams (myfield1 c(10), myField2 i, myField3 d)
>m.myField1 = [Textvalue]
>m.myField2 = 1234
>m.myField3 = DATE()
>INSERT INTO crsMyParams FROM MEMVAR
>
>
>Now you've got a cursor that, as long as you don't use private datasessions, can be accessed by any form in your project. When using private datasessions just add this line of code:
>
>
>CURSORTOXML([crsMyParams],[cXMLParams],1,1+2+4+8,0,[1])
>
>
>Now you've got ONE variable which contains up to 255 parameters. Call your form with this string as a parameter and your form/app can access the values simply by converting the XML back to a cursor.
The whole reason experts say not to use public variables is because they can be changed by anycode to any value - making the system dependent on such values leads to instability.
All you've done by using cursors and parameter objects glued to _screen is to define a new type of public variable.
Parameters and parameter objects are supposed to be PASSED to functions. Code is not supposed to expect parameters to exist. Code is supposed to accept parameters.
The parameter object has no 255 property limit so is far more flexible.
