I figured that's you were trying to do but it's a bad idea for a number of reasons. Page is a heavy object and you don't want to be passing your UI component into some other processing code. So from a design perspective it's definitely not optimal.
With ASP.NET you have the additional issue that you don't actually know what the page type is until runtime which has the effect that you can't strongly type your page class easily.
There's a CodeFileClass attribute you can apply at the @Page level which gives you the ability to give an explicit name to your page class. You can then reference that as the type to pass as parameter and that should give you the controls.
Ultimately though the other approach of using objects to actually load your data into is a much better approach.
What I do is have business objects that bind page content. I can then unbind the data from the page into the business object's entity properties and that's easily passed around.
Here's the databinder (well an older version) that I created to do VFP style databinding in ASP.NET:
http://msdn.microsoft.com/msdnmag/issues/06/12/ExtendASPNET/default.aspx?loc=enThis should give you an idea of how this can be done.
+++ Rick ---
>>>I want to pass object 'this' from a page code to a static method in a class in .cs file. In the called method, I need to define what type is this object. How do I define it?
>>
>>If you use standard ASP.NET projects the class name is dynamically generated so the name is not available to you, at least not for the final class. You CAN pass the name of your code file class however.
>>
>>loObj.MyMethod( (MyNamespace.MyPage) this );
>>
>>With Web Application projects you can define the name of the generated class as well and you can use that name instead and get full support.
>>
>>In general though I don't think this is a good idea. You should never pass a Page object to anything. If anything you should create an interface that has the properties/methods you want to expose and then have the page in question implement that interface, but even that is not a good idea. THere's no reason you should ever pass a user interface component around.
>>
>>Instead any data you care about should be attached to some sort of data object (or a business object) and you acan then pass THAT around more effectively.
>>
>
>I think the last paragraph defines what I should learn to do - create some kind of a business object and pass it around. Let me explain why I need to pass THIS/PAGE (and I agree and learned that it is not possible) to a method of another class. In that method of another class I need to get .Text values of the page controls. E.g. This.MyTextBox.Text and so on. These values are only "available" in the Page class of the application, however. So I guess what you are saying is I need to create an object, set values of all my control .Text to this object and then pass it around. What I don't understand is where to start <g>. This object that will be passed around, where do you create it, and how do you use (instantiate) it in the page class?
>
>If the answer to my questions are too basic and require too much of explanation on your part, feel free to ignore it. I won't take it personally, I will just have to hit the books.
>
>Thank you very much for your help.
