Inheritance Strategy

I am a bit stumped on how to use inheritance to solve my problem. I am using a non-MDI interface main form that creates and displays user controls (rather than new forms) to display data to the user for browsing and editing. I have a base class called ViewPane. All viewpanes will have a grid style list control and a dataset, however they will each naturally have different schemas. Most of the methods of the viewpane are generic in that they apply to every viewpane such as navigating records and reacting to application events such as cut and paste. Some of the methods apply to all instances but are implemented in different ways such as updating records. I have the concept of overrides somewhat down, but it will not let me override an object declaration on the base class.

I tried to add an untyped dataset and an unbound grid to my base, but I couldnt modify these in the inherited controls. I then tried to add a new strongly typed dataset and bound grid with the same names as the base class controls to the inherited control using the Shadows keyword and this didnt have the results I expected. Mostly got "Object reference not set to an instance..." errors. As I write this it occurs to me that maybe I should be trying to modify the dataset and grid in code at run time rather than in the designer at design time??

I don't want to rewrite code to manage all these grids and datasets on each user control that is identical just because the grids and datasets are not indentical. Help!
Thanks :)

Who is Participating?
BigRatConnect With a Mentor Commented:
If I understand you correctly it's like having :-

    TMyCustomForm = class(TCustomForm)
                                 Grid : TCustomGrid;
                                  DataSet : TCustomDataSet;
                                  Button1 : TButton;

                                  procedure OnButton1Do;

You then program OnButton1 (inter alia) to perform actions on the Grid and the dataset.

Later you actually define the real objects by "filling in" the asbtract classes.

Of course this won't work!

What ones does however is to define the abstract objects via interfaces and code up the standard actions against those interfaces. When you define the "real" form your constructor "constructs" those objects (assuming of course they match the interfaces).

ChipzterConnect With a Mentor Commented:
Perhaps you could declare the objects that are to be overridden in the subclasses as protected readonly properties? It would also be prettier to make the super class MustInherit and the properties MustOverride, but that would break the designer.

A pseudo example:

Public Class FormBase
    Inherits System.Windows.Forms.Form


  System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()
        Me.DataGrid1.DataSource = Me.FormDataSet
  End Sub

  Protected Overridable ReadOnly Property FormDataSet() As DataSet
            Return theDefaultDataSet
        End Get
  End Property

End Class

Public Class Form1
    Inherits FormBase
    Protected Overrides ReadOnly Property FormDataSet() As DataSet
            Return theOverriddenDataSet
        End Get
    End Property
End Class
cbasultoAuthor Commented:
I am going to use both of these solutions. I realized after more thought that many of the methods were extensions of either the dataset or the datagrid class, so I am going to inherit from these and create extended classes which I can use in my forms with fewer lines of code, but in some implementations being able to pass the overridden object as a property would work well.

Thank you very much.
All Courses

From novice to tech pro — start learning today.