There is a class that I want to create as abstract but I can't because that class's base class is ActiveReports and as soon as I make it abstract the sub-reports are no longer designable. (Interestingly the base class itself IS designable but not it's children).
I know that I cannot declare class members as abstract without first declaring the class as abstract.
In this case what is the NEXT BEST way to do this. At this point I made the members virtual and added comments to each one. Where it made sense I also declared a member as protected rather than public. But is there some other best way that would REQUIRE that these members be overridden at compile-time rather than run-time?
If you were in this situation how would you do it?
EDIT
Let me explain further. I can create a class (lets call it MyReportsBase) that inherits from ActiveReports. (I do that using add new and choose the ActiveReports type) Then ActiveReports provides a property of the report object in MyReportsBase (in design time properties) called MasterClass. Once I set that property to true then I can then create new reports and inherit from MyReportsBase instead of directly from ActiveReports. (The way you do that is by create add new ActiveReports but then edit the code in the code-behind to inherit from MyReportsBase instead of ActiveReports).
That is all well and good and it all works perfectly well. However, my requirement is that MyUpwardBase would HAVE to be inherited (declared abstract with a few abstract members). And I CAN go in the code-behind and set the abstract modifier on the base class. And even then I can design MyReportsBase. However, at that point, all of the reports that I inherited from MyReportsBase are no longer designable. Attempting to open the derived reports in the designer throws an error about how the designer cannot open the base class because it is declared as abstract.
All of this is to just clarify the question. Right now the Interface suggestion is making the most sense to me.
EDIT 2
An Interface doesn't really do it for me either for this reason. The base classes "abtract-but-aren't-abstract" members HAVE To be present in my base classes because I have virtual and public members that depend on them. And in my case, because I cannot declare the class as abstract, I have to have an implementation for those members.
As soon as I provide an implementation for those members then all of my inheriting classes ALSO have the implementation and the Interface doesn't complain at compile time. I thought by removing the virtual modifier from those members that the compiler would require them but it did not behave that way.
I am beginning to think that my solution (document the members well) is the best solution.