Frequently Asked Questions about the Display Machine

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.

How can I...

What about...

The first screen

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

The feature to which the widget is bound

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.

Activate a form from another one

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.

Coupling and decoupling classes and display

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 display in the class text.

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 display in the underlying classes.

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!

Database access

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:
  • Maintainable
  • Reusable
  • Safe

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.

Modal and modeless forms

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.

MDI forms

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.

TAB windows

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.

Radio buttons (and other integer formats)

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")

Menus

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":


Copyright © Object Tools -- info@object-tools.com
Last updated: 2005/02/02 11:51:08