ModelMaker Tutorial 5

Tutorial 5 — Implementing Classes/the Member List

by Robert Leahey of Thoughtsmithy

Introduction

Tutorial 1

Tutorial 5

Figure 17 — the Member List.

Given the wide range of options available in adding class members, this step is more informative than tutorial.

Ok, we’ve looked around enough — it’s time to get serious about implementing our classes.

The pane that you’ll need to get to know well is the Member List (see figure 17). This window is found below the triumvirate of the Classes View/Units View/Diagrams View.

The Members List allows you to manage the members (fields, methods, properties and events) of your classes. Note that there are many options that control the appearance of the Member List so my screen shots may not look the same as the Member List in your copy of ModelMaker.

The first thing to notice is that the Member List is just that — a list of a class‘ members. Remember that ModelMaker keeps an active model of your code internally and that all of the various editors are simply different views into the model; the Member List is another example of that. Any changes you make here are simply changing the model, not the physical source code files (unless you have Auto Generation Enabled) until you generate the source from the model.

On the General tab of the Environment Options dialog (available from the Options menu) is a group box entitled Members Appearance. If you check the first three items, Display Type Bitmaps, Display Visibility Bitmaps and Display Info Bitmaps, you will see all three columns of graphics in your Member List (as shown in figure 17). Select all three options and we’ll have a look at the various icons presented in the Member List.

The first two columns in the Member List represent the member type and visibility:

— Field	— default visibility
— Method	— private
— Property	— protected
— Event	— public
— Method Resolution Clause	— published

The third column displays a contextual icon depending on the member type. For methods, the icons represent bindings as follows:

— static	— virtual	— override
— abstract	— dynamic	— message

If the member is a property, the icons are as follows:

— Read/write

— Read-only

— Property override

The Member List allows you to add and edit members as well. Here we will take a general look at that process.

Figure 18 — Add
Members toolbar.

Near the top of the Member List, you should see the toolbar in figure 18. The first four buttons on this toolbar are for adding members; they are, from left to right, Add Field, Add Method, Add Property and Add Event. Clicking one of these buttons will display the appropriate editor for the memeber type you selected. You should notice some similarities in each of the editors: Name, Visibility and Type. Also common to each editor is the Documentation tab where you can add documentation for your new member. The documentation you add is attatched to the member within ModelMaker‘s internal model and can be used in a variety of ways. For example, you can emit the documentation with your code as comments (see Tutorial 7) or link to it within a diagram as an annotation (see Add Documentation Link and Add Linked Annotation in Tutorial 4). It is also available via the ModelMaker OpenTools API (see Tutorial 10).

In addition to the common elements, each editor contains settings specific to its member type. For instance, in the Property Editor, you can control the property‘s read and write access while the Event Editor allows you to generate a dispatch method.

Here are some quick thoughts on each of the member types which should help you to get more comfortable with ModelMaker:

Fields and Methods

If you‘re trying to add a propert‘s state field or an access method, stop. One of the key advantages of ModelMaker is its automation, and the automation surrounding the creation of properties is high. See the next section for more information.

Make sure you visit the ModelMaker online help by pressing F1 in the editor dialogs. Some items of note are the Owned and Initialized options for fields and the Inheritance Restricted option for methods.

Properties

As mentioned in the previous section, ModelMaker can greatly simplify the process of adding a property through its automation features. This is one of the reasons many people choose to work in ModelMaker as their code editor (as a Delphi IDE replacement); when adding a property by hand in Delphi, you write the declaration code for the property, its access methods, perhaps a state field and the implementation code for the access methods. When adding a proprty in ModelMaker, you add the property. Period.

Within the Property Editor you will find options for specifying the read/write access for the property (state field, method or none) as well as for generating some rudimentary read/write access code. Once you have set these options and clicked OK, ModelMaker adds not only the property, but the related access code. The generated code is “owned” by the property — if you change the name of the property or delete it, all the generated code is automatically renamed or deleted as well. Try experimenting with these settings and read in the online help for more information.

Events

Adding an event is somewhat similar to adding a property; most of the overhead is managed for you by ModelMaker. In the Event Editor dialog, you select a name, event type (event types are managed in the Event Type Library, available in the Events tab) and visibility. You can also specify a dispatch method by checking the Dispatch checkbox. The generated method will be owned by the event similar to the way a property owns its access methods.

Note that if you wish your dispatch methods to automatically be prefixed (with “Do”, for example) you can specify this and other coding style options in the Coding Style tab of the Project Options dialog under the Options menu.

Return to the Introduction.

Go back to the previous tutorial.

Go on to the next tutorial.