I see your point. Maybe VS.NET uses the base class of the code-behind class to contain all the components in the designer? It would be difficult to use the code-behind class since it is likely not in a state that would allow it to be compiled. They would have to use the base class, and not just System.Web.UI.Page, since folks like yourself might want stuff to derive from some other class.
This is just a guess, however. -John http://www.iunknown.com -----Original Message----- From: DEAL John M [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 2:22 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.Net Abstract Base Page Inheritance I don't quite buy into the "designer attempts to instantiate the Page class... and of course it can't instantiate an *abstract* class" aspect of it. The point is the page that is being designed is a concrete version of the abstract class and it is that concrete class that should be being instantiated (no different than at runtime). I could buy if it complained that I hadn't implemented an abstract method in my concrete class, but not that the designer should be trying to instantiate the abstract itself (what would be the point of inheritance if you never got to the concrete class?). I'm really not trying to be difficult, I just don't see why the designer would ever try and instantiate the abstract class. John Deal -----Original Message----- From: Marsh, Drew [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 11:07 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.Net Abstract Base Page Inheritance DEAL John M [mailto:[EMAIL PROTECTED]] wrote: > Also, > as I mentioned, this behavior is prevalent even if the base page has > all non-abstract methods defined but the class itself is abstract. Right, the problem is that the *class* is abstract. Like John said, the designer attempts to instantiate the Page class... and of course it can't instantiate an *abstract* class. > I would have thought that the behavior would be to ignore any of the > abstract definitions until compile time (throwing exceptions where > necessary) and still display the visual elements as usual. It's not the methods causing a problem, it's the class. If you want design-time on this page, you're just going to have to go with John's suggestion of making the methods virtual, raising exceptions at that level and leaving the class as non-abstract. Either that or you can't design the base page. HTH, Drew NET MVP You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
