Mike,

in context ...

>>I just store any return value in a property of the modal form - i.e. "xRetVal" then it is available to the calling method via that property.
>
>Well, you're probably not gonna want to keep it in xRetVal, so you'll have to copy the property to the real property like you would with a second temp object.
this assumes I need it in a property - most times I don't - it's just a string or a number ... don't get over-ooped!

> And if you want multiple return values, you'll have to give them better names.
agreed

>What if you want to get the return values and then validate them before you apply them? If you make the changes to the calling object directly, you can't revert them (unless you want to store local backup variables for every property and revert them?); if you make the property changes to a temp object, you now have a buffer.
If the calling object doesn't like the return values - it can re-show the form - remember - it's just hidden - not gone. As my daddy used to say - you're killin' snakes that don't need killin'

>If you have names like "cCaption" as a value returned from a class, and aren't aware of that because someone else developed the class, it may squash the "cCaption" you added to your class for another purpose.
not sure what you're trying to say here ...


>The worst part about the method is that its inconsitant depending on if you call it from a form or a PRG, whereas a temporary parameter object uses the same code.
?????

>>This method also has the advantage of allowing you to access all the controls on the modal form.
>
>Like Dave said, you're putting resusablity and maintainablity at large risk by this.
>
>Wanna change the name of a textbox in a class? Ohh, you have to make 5 changes to 5 different methods in 5 different classes to use the new name instead of 1 method in the same class or on the same form as where you made the change to the control.

And if use was going that way - I wouldn't do that - Mike - dude - you need to realize that different scenarios can use (or require) different techniques. If I have modal form that has one special use in one place in one app - it is not necessary or in any way "better" to abstract it out inthe name of decoupling when direct references work just fine. If the form is going to have (or might have) multiple use - I would agree and handle it differnetly. I am not opposed to passing in a parameter object - but for simple return values - and xRetVal work just as well and causes no complications and no in way limits subclassing - etc.

BTW - to you and all -Idon't make a habit out of directly referencing controls on a called form from the calling object - I just pointed out that you could if needed. I would agree it is not a very good way to deal with it.