I'd be very careful with this approach. There's a reason that Microsoft decided to make all the controls on a form Private <g>... i think an outside in approach works better in this case if you only need a few specific tasks to perform on the 'called' form by adding methods that do what you need. I would refrain from trying to drive the called form from the active form and make sure the code that performs anything on the called form also resides on the called form.

The same goes for business objects - always call either the form to manipulate its contained business objects or somehow have a handler method that manipulates the business object.

Realistically this doesn't cause more work, but potentially a little bit of method bloat on your called form. Instead of using the calling form's Click() event to perform tasks just delegate to a form method of the Called form.

All of this will save you a lot of headache later on trying to debug or maintain the app as it maintains encapsulation, even if it may appear to be more work at this point.

+++ Rick ---

>I'm sure this is a simple one, but to this day I'm still missing it.
>
>Let's say I have Form 'A', the main MDI parent. Someone launches Form 'B', an MDI child form.
>
>Form B is a complex form with a fair amount of business logic. I'd like to be able to take all the business logic and create a separate class module [something like Form_B_Logic]. The logic in this class would need to 'see' and read the contents of the controls in Form B. And that's where I get stuck...if I pass the form object as a parameter from Form 'B' to the Form B Logic class, the class doesn't see any of the controls on Form 'B'.
>
>Again, I just want to create a class of rules for each form, where the class can examine the form object and 'see' all the controls underneath. That way, the form itself has nothing more than the controls and function calls to the form class logic. It's one of these cases where I knew how to do this in VFP, but haven't figured out how to implement in .NET.
>
>Thanks,
>Kevin