>That's really dangerous. If another new method calls ValidatePass and doesn't set the property, you could get strange results. This is the kind of thing that will be difficult to debug. Do it the right way. Refactor to a parameter object. I would not recommend XML unless it's being called by a non-VFP application. Create a customer object with one property for each parameter.
>

The C++ application is calling this VFP dll with XML string. This application is going to pass something like this

	<func>checkpass</func><tcdptcatitm>PASSES    STORY 9548VALIDNITEM</tcdptcatitm><tcoperator>ADMIN</tcoperator><tcphyslocation>
	</tcphyslocation><tcprefix>P</tcprefix><tcreturntype>STR</tcreturntype><tcsalespoint>RESERV001001</tcsalespoint><tcwhichkey></tcwhichkey>
	<tnnumvals>1</tnnumvals>
	<tnpassno>70001001</tnpassno><tnscanno>70001001</tnscanno><ttScanDateTime>08/22/2014 02:07 PM</ttScanDateTime><typrice>2</typrice><tnExtraDays>30</tnExtraDays>

The VFP application gets this string, parses parameters and using very long case statement calls appropriate method with appropriate parameters. So, in the main Invoke method of this VFP dll I get the tnExtraDays parameter, set it and then follow the logic.

I believe it's going to work fine as a class property now which is set in that Invoke method vs. adding an extra parameter to a few methods. In fact, this is what I already implemented and going to send to build soon. Then our QA department will test it for various scenarios (I did a limited quick set of tests myself directly in VFP).

This is how our VFP olepublic class is build. Lots of methods are extremely long, have many return points, etc.

In any case, we're re-writing this into .NET while still maintaining and adding user enhancements into that old VFP code. I can not do major re-factoring of that code and it will not be practical.