From a pure technical POV and the info provided your solution is stupid patching.

As the vfp app is probably phased out / EOL, that might make economic sense - but the technologically correct way for that many parameters REALLY needed is to create a parameter object. If the parameters are really always extracted from an XML or JSON string (and a sensible naming mapping was defined and followed both in XML and parameter names), creating the parameter object frm the string can be handled by a global function, perhaps with an exception naming list to correct for all cases where naming convention was not followed.

There ARE reasons for some info to be living in properties, other always being specified as parameter from the calling function. Overflowing the latest info additions into properties is WRONG. There is a good chance that some of the previous parameters should be properties, as functions with that many parameters are suspect, but if there was a decided upon convention to always use parameters, stay with it and create a parameter object. Anything else adds to maintainance cruft.

If naming conventions were in existance and strictly followed, a half way automatic/easy method to refactor could be to examine the XML/JSON names of the string to be put into parameters and put those with a specific name prefix into class properties. That way you could put the info where it makes sense into properties and not just the late comers.

Sounds like the vfp code missed code and architectural analysis so much it was maintained to the grave - do not add to such a process.



>>>It is an existing method of a class and we're normally passing everything as parameters. Here is the current declaration of this method
>>>
>>>

>>>procedure ValidatePass(tcSalesPoint as string, tcOperator as string, tcPassTable as string, ;
>>>		tcWhichKey as string, tcPrefix as string, tnPassNo as double, tcDptCatItm as string, ;
>>>		tnNumVals as integer, tcPhysLocation as string, ttScanDateTime as datetime, tnParentNo as double, ;
>>>		tcNoTrans as string, tnScanNo as double, tnSiteNo as integer, tcScanNo as string, ;
>>>		tcCheckpointName as string, tcCheckpointValue as string, tlTrickle as Boolean, tyPrice as decimal, ;
>>>		tnTransNo as double, tnCreatedPassNo as double, tcAutoSaleDCIs as string, ;
>>>		tlFromScanner as Boolean, tcPassNo as string, tnBenefitID as double, tcMbRedemptions as string) as string ;
>>>		helpstring "Process a validation for a passholder record including updating record and recording log entries."
>>>	

>>>
>>>So, normally I would add an extra parameter (as I need to add tnExtraDays parameter). I guess I have no other choice but to create nExtraDays property of the class and use it instead and re-set in each call. The problem is that I already coded another method to use parameter and for consistency I think I'll change that method as well to use that new property.
>>
>>If it is contained, such as a class calling a method of its own, I would use parameters. This usually does not evolve and are usually limited to a few parameters. For client applications, calling those class public methods, I would pretty much always use class properties.
>
>The outside application that uses this dll passes all parameters as XML string. The VFP dll then parses that XML, finds out which method was called and then passes all of them as parameters.
>
>Since in this particular case we're close to the limits of VFP as number of parameters of a method, I think I have no other choice as to have that parameter to become a class property instead.