> That's not allways the case though!!!!

That's why I said probably. :)

Really though, from your brief message, here's what I would guess. You have a control on a form that provides some service, you now need to have that same service take place someplace else, so since you already have the code in another object, you figure you'll just call that object. This is usually an indicator that the code should be someplace else.

The other scenario is that you have a control on this other form that you need to directly interact with, perhaps to refresh it or display a total let's say. After you figure out the object reference, you're going to end up with some code, that, for the sake of argument looks like: loForm.PageFrame1.Page1.txtMyControl.Method(). Code like this is very fragile, IOW, if the object reference changes, it breaks, if you decide to support multiple instances of the form, how will you know which one you're talking to, etc. It would be better practice to create a reference to the object someplace else so you could do something like oControl.Method(). In a lot of these scenarios, the form that needs to communicate with the control on the other form is some type of child form, or at least launched from the first form. If that's the case, when you call the second form you might want to pass a reference to the control to it, then your code can reference thisform.oControl.