a parameter object was suggested and you asked, how you could still use a command in the menu designer, so you'd not have to change to procedures in the menues.

You can use a factory and let it create the parameter object on the fly. The factory.createparameterobject() method then would take a token (like a class name) and/or a list of property/value tuples as its parameters.
eg goApp.oFactory.createparameterobject("iX;10,iY,100") would result in an object with properties iX and iY, their values being 10 and 100. So youd put in that call to the createparameterobject method and it would still be a one liner.

I also like Tores idea of using This_access() to create properties on the fly, as they are accessed or assigned first. But that introduces a source for harder to find unobvious errors, if you make a syntax error or typo while setting or using those properties. Eg. if you add oPar.lTrue=.T. when creating the parameter object , pass that object, receive it as toPar and then access toPar.lTreu, you'd not get an error but .F. instead of .T.. And of course you'd then need a procedure for each menu item.

You could of course use the parameter string solution itself to pass any number of parameters within one string parameter. That may also be XML and contain whatever complex structure. But having a factory that produces ready to use objects makes life simpler. The form handler receving it at first would just pass it through to the form class and the form classes would just use the objects properties instead of parameter names.

By using WITH..ENDWITH the code changes are done fast, but still many changes are of course needed to make your forms run on those parameter objects. It's worth it.

Bye, Olaf.