Be consistent in the presentation:
|
Button size |
Buttons should be of the same size throughout the application. |
|
Button labels |
If OK means validate changes, make sure that all buttons having that action are labeled OK. If OK buttons are red, make sure all OK buttons are red throughout the application. |
|
Button order |
If the OK button is on the left of the Cancel button, make sure that this is always true throughout the application. |
Be aware of screen resolutions:
Do not assume that all users run the same screen resolution. Create screens for the most popular screen resolution, which is, 800x600.
Make sure that the form fits in the browser and does not require scrolling if creating Web applications.
Event-driven applications are very different from procedural applications. In an event-driven environment, the user clicks anywhere on the application in any order. The developer needs to be in control and handle all cases. Each event generated by the user (that is, mouse clicks, keystrokes, and so on) must be properly handled by the application.
mvDesigner is based on an object-oriented Rapid Application Development (RAD) tool. As such, mvDesigner inherits all Object-oriented concepts of the original environment (that is, Omnis Studio); however, mvDesigner does not require object-oriented Programming skills. There are key features that need to be understood in order to take full advantage of the mvDesigner development environment.
In mvDesigner, the developer is confronted with three types of objects:
Visual Components or Visual objects
These are objects that you drag from the Component Store to the design form to create the screens. For example, these are buttons, list boxes, grids, and so on and by themselves are of no use. They need to be assigned data for display and events for action.
Each Visual Component has a set of properties and events:
|
Properties are object parameters that identify the way objects look. |
For example, most objects have a textcolor property which is used to set or change the color of the text the object displays. |
|
Events are sets of behavior an object can handle. Events are not limited to mouse actions. |
Keystrokes, COM ports, and so on also generate events. For example, most objects support the click event. A click event is triggered when the user clicks the mouse while the cursor is positioned on top of the object. You can instruct the object to perform a certain task when the click event occurs. |
|
NOTE |
Not all objects support events. Background objects do not support events. Background objects are considered painting objects that are only used to make a form look good. These are the labels, lines, wash, and so on. These objects do have properties. |
Instance Variables
Instance Variables are non-visual objects that hold data. When associated with a visual component, the data is displayed through the visual component interface. For example, a list box needs to get data from an instance variable in order to display data in the list. mvDesigner provides an easy interface to associate instance variables to visual components.
mvDesigner instance variables start with iMvdRow.
|
NOTE |
An instance variable can be assigned to more than one visual component. Some visual components require more than one instance variable. Some grids can also have multiple instance variables assigned. |
DataNames
|
BASIC |
DataNames are used to associate BASIC data to instance variables. If the data of the instance variable needs to come from a BASIC program, you tell mvDesigner where the data comes from. |
|
mvDesigner |
DataName is a property of the visual component. Use this property to assign the instance variable to the component. The data displayed by the component is held in this instance variable. |
|
NOTE |
A DataName can only be associated to one instance variable. For example, the combo box component has a DataName for the edit field and one for the list field. |
See Also