>Hi Mike,
>
>>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.
>>
>
>You're absolutely correct. Those values can be changed by any other code.
>
>In case of constants I am absolutely by your side. In case of parameters, I don't have a problem with an object temporarily glued to _screen. The form that needs the information can delete the object anytime as soon as it reads them.

The fact that any form could delete or otherwise alter this basically public object is the problem.

>
>>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.
>>
>
>Indeed, functions should accept parameters/parameterobjects. In case of a form, I don't have functions, I have methods and events. Usually I am working a lot with bindevent() to trigger special methods. Those methods will work with properties...

From the perspective of passing parameters there is no difference between functions/procedures/methods/events (except that you should not call events).

>
>OK, OK, I also have several older UDFs that definetely are in need of params... ;-)
>
>
>>The parameter object has no 255 property limit so is far more flexible.
>
>This is correct, however, if I ever have the need for so many properties, that have to be set from a calling form or app, I will definetely try a table-based approach. However, I have to admit, that the apps that I am working with usually don't need so many params. :-)

I think there is a huge benefit in using and mastering a single technique over having several other choices.