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.

>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...

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. :-)