In each case you should make sure that you have read the white paper and the short tutorial about DM. We also recommend looking at at least two examples.
it depends what type of DM you are using. We will describe the standalone application. Everything is extremely simple: just create your object and display it. This can be done for example in Eiffel with:
a: CALCULATOR -- the declaration ... !!a.make -- create the object a.display (1) -- call the first form designed for this class
After return from display(1)
the object a
contains all the
information entered in your form. So you can for example (provided that you use the
calculator we defined) access the display with:
sum := sum + a.indicator -- add calculator's display value
Select the feature on the form. The fully qualified feature name appears in the status bar cell. Alternatively, you can open widget properties, then the fully qualified feature name is displayed in the dialog title.
you should have a look at the advanced way we have described. The point is that you can
use the (inherited) feature display
as action associated to any part of your
form. So, if you have entered a number, a new form will appear (if you want ;-). See a
more advanced example.
Designing DM applications can be done in two ways - the traditional way, which keeps close coupling of classes with the forms; and the more advanced way, which allows building complete applications on top of the class collection.
The traditional way |
The advanced way |
---|---|
You can use the routine display in order to display and
to modify your objects directly. In all places where you need input or output, call the
object's display with the proper form number. This approach is convenient but does not
decouple the RAD application from the classes as much.You can recognize such
applications by the large number of calls to |
You should use display mainly as actions related to
widgets used in forms - for example in the action related to a button or a menu
item.The
GUI application itself will be responsible for the control flow. You can recognize
these
applications by the missing calls to |
Your applications may sometimes be between. You should try to minimize the
calls to display
in your class text - leave only the first one which starts the application. So, stay on
the more advanced side!
In traditional RAD packages database access is the main task - reading some data and producing fancy reports.
DM is not designed for such tasks. This doesn't mean that such things are not possible - they can be done much better. You know: |
|
1 The database access must be written as part of the class. The object should write itself to the file using the proper method and this code should be provided as part of the design in order to meet all safety requirements. In typical object-oriented environments such writing will not only dump a record - it could store a whole collection of "leaf objects".
So lets assume 2 that there is a feature save in the class CUSTOMER which a programmer designed in the usual object-oriented way. This task is not trivial - especially if the CUSTOMER is a composite object with references to other objects which must also be saved (but only if necessary).
For storing the data there may be many different possibilities - and, 3 worst of all, at the time the graphical application is written, the database design might not be frozen - even the type of the database could be changed during the lifecycle of the application.
The company has always used a relational database. Nobody ever thought about object-oriented databases. But now, (we write March 27, 2001) with the release of the universal object-oriented server from *** relational databases are historical events. | No problem - we have to rewrite the save features in our Knowledge classes. We don't even touch any application - they will work without any problems. |
You've probably got the point: DM requires some more work (in fact "brain work") to put the bones and flesh into the application. But this investment will pay back very soon.
(the same strategy applies for reading an object. Here the design is not as clear because the object probably does not exist before it is read, so different object-oriented designs can be applied)
The commercial version of DM will contain an assistant which supports useful design patterns to create such an interface semi-automatically.
Display Machine supports both modal and modeless forms. Forms are modal by default. To make the form modeless change the corresponding property of the form.
The Display Machine has support for creating MDI applications. These applications consist of the main form (MDI Frame) with a common menu and a number of child forms (MDI Children).
To achieve MDI functionality in your project, assign "MDI Frame" value to the type property of the main form, and "MDI Child" - for all child forms. It's just that simple. Keep in mind that MDI Frame form must have user menu, which could be activated with the corresponding property of the form.
At first one must select the location of the TAB windows. This is done by pressing the left mouse button and moving to mouse in the right lower direction. This draws a rectangle and opens a selection box. Now you can (beside other things) add a tab area.
In a second step one has to open the property box of this tab area and select the windows which would be contained (Note that these windows must be of type TAB Page). That's all.
clicking on a integer attribute of a class gives some choice of integer representation:
In our case we select the radio button - we can even drag&drop instead of the attribute the radio button symbol into the form area. To get a proper radio button we should do this at least twice - and we should set in the property window the possible integer values the attribute should set to if the radio button is pressed.
On a similar way we can produce some other representations: trackbars, up/down buttons and more. A (not so typical ;-) form created with only ONE integer attribute looks like:
(this "design" was really done in less than one minute - and all widgets are in fact "synchronized")
are part of a form and must be activated by setting the user menu property for the form. The property dialog box for the form will be extended with a menu property page. Now you can set the type of the menu item, the text and the action associated with the menu selection:
It is possible to enable the selection dynamically.
Setting the properties of the menu item changes automatically the picture of the form:
The picture below shows the form at "run time":