Subclassing SF StandardForm

This sample application demonstrates some of the possibilities of sub-classing the MicroFour.StrataFrame.UI.Windows.Forms.StandardForm to extend the functionality of that class.

The EgBaseForm is a class that inherits from the StandardForm and extends it as follows:

• Form's caption (Text proprty) can be automatically updated to indicate the current record.
• The form can auto-load it's BO in a few different ways, depending on how it is configured.
• The form can auto-navigate to a record within the loaded data
• The form can open in DataEntry mode, ready to allow user to enter data.

To test is out, try the following:

1. On the menu strip, click on the Add Customer menu item. The CustomersForm opens with no data loaded and on a new record ready for data entry.
2. Enter a customer ID between 1 and around 19,600 (assuming you have the standard SF sample db installed), then click the View button beside the ID text box. The CustomersForm opens to that customer.
3. Select a letter in the Select Last Name Start combobox. Click the View button beside it. The CustomersForm opens loaded with all the customers whose last name starts with that letter.
4. With the form opened from #3, select a customer that isn't the first one in the form. Enter this ID in the And Nav to textbox. Click the View button beside the letter combo. The CustomersForm opens with all the customers whose last name starts with the selected letter AND it has navigated to the ID you entered.
5. Enter customer ID #2. Click on View next to the ID textbox. Select an order (there is likely only one). Select View Orders. The CustomerOrdersForm is shown with all the orders for that customer, with the selected order navigated to. This uses a fill method in the derived form, but adds the feature to auto-navigate to a specific record after the BO is filled, which is coded in the base form.

Using Generic Factories

An interesting thing to note is that the sub-classed form has a set of shared (static) "factory" methods that create instances of forms derived form the base class (EgBaseForm).  The factory methods allow for the features of the base form that are more runtime driven (as opposed to being design time driven, like the auto-caption update feature) to be more easily used (one method call, rather remembering the combination needed for a feature). For each feature there are two methods: a function to create a form with that feature and a config method that configures the form to use that method. So, feature that can auto-load the form with a single record based on the BO's PK, is supported by two methods:

• CreateSingleRecordForm - create and configure a form that will load a single record into the BO.
• ConfigSingleRecordForm - configure an existing form to load a single record into the BO.

Typically the create function is used when the form simply needs the features of the base form, nothing else. The configure method is used when the form needs that feature, among others. For example, if a derived form had a constructor that indicated a parent ID of the records to load, which was required, then you could first create an instance of this form, using the parent ID, then call the config method to configure it load a specific ID. The config methods also allow for the features to be easily combined (as makes sense).  The CreateAutoLoadAndNavForm shared method does just that. It creates a form that is configured to load data and then to navigate to an ID on load.

They are generics so at runtime they can still be strongly typed. But because the code is in the base form, it only needs to be written once and is maintained in a single place.