We had considered that (virtuals that default to thrown exceptions) but thought it was a bit of a kludge.
As for the page actually running (I'm assuming you meant at design time rather than runtime), I'd go with that being the problem if the abstract methods had anything to do with the designer, but they are runtime business logic and error management routines, there is nothing visual about them that could interfere with the designer display of the page. 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. 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. Thanks for the ideas, John Deal -----Original Message----- From: John Lam [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 10:10 AM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] ASP.Net Abstract Base Page Inheritance It's not a bug - it's the way VS.NET has to work. At runtime, the "page" is actually running, and the components on the page are instantiated by VS.NET, and running in the context of the page designer. Instead of implementing your methods as abstract, why not implement them as virtual methods and throw an exception in your default implementation? -John http://www.iunknown.com -----Original Message----- From: DEAL John M [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 22, 2002 10:56 AM To: [EMAIL PROTECTED] Subject: [DOTNET] ASP.Net Abstract Base Page Inheritance Hi All, The project that I'm working on has a number of functionally distinct ASP.Net page types that we repeatedly use. To simplify the coding involved with this we decided to create base pages for each of the distinct types of ASP.Net pages. For some of these we decided to implement one or more abstract methods, so that programmers creating new pages inheriting from the base page would be forced to implement page specific methods required by the base page. The abstract methods in turn require that the base page also be abstract. When we did this everything compiled and ran fine (i.e. if we changed the code behind page to inherit from the abstract base, the page would compile and could be viewed in the browser). Where we encountered a problem was when we then tried to use the VS.Net winforms designer to add controls to the web page, it refused to enter Design view and spit out an error stating "The file failed to load in the Web Form designer. Please correct the following error, then load it again: Type Abstract". To make sure it wasn't some funky code we added to the base class we created a simple test where we created a new class that inherited from System.Web.UI.Page called page base and made the class abstract (note we did not add anything to the class, making it essentially a pass through). We then inherited the abstract class into a new web form, the web form would then exhibit the behavior described above (i.e. it could be compiled and viewed, but not designed via drag and drop). Our best guess is that this means that while it is valid to inherit from abstract classes, that the VS.Net IDE has some bug that won't allow it to be visually designed. Has anyone else out there encountered a problem like this? and whether or not you did, do you have any explanations that might shed some light on why this is the behavior? or any suggestions with how to deal with this problem? I've tried looking around for an answer for this elsewhere, but I can't seem to locate anything (or can't seem to phrase my search criteria correctly :-) so any input would be greatly appreciated. Thanks. Have A Better One! John Deal You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
