With Paradox, you can create forms and reports visually. You can create dazzling single or multiple forms for viewing, editing, and adding data. This chapter shows you how to begin integrating design elements into a complete application. It deals with issues, problems, solutions, and tips with design documents from a developing point of view. A design document is a form or a report that a developer uses to display data. This chapter also dives into special, summary, and calculated fields.
The user interface is the first element of your application that a user sees. Because first impressions are important, the user interface carries more weight than any other part of your application. It deserves much planning and effort. While developing Windows 95/98, Microsoft spent a great deal of money and time planning and testing the user interface. The efforts of Microsoft are apparent in the user-oriented design of the Windows 95/98 operating system. If you are a Windows 3.x developer and you are developing your first Windows 95/98 application, then you owe it to your users to study and learn the look and feel of the new operating system. When you deliver an application that has the look and feel of the operating system, the users are instantly familiar with the your application and its user interface. Instead of trying to learn a new user interface, the user focuses on learning how to do the task your application is intended to deal with.
Often when you start a new form, you already have an idea of what you want it to look like. When you’re inspired, go with it and harvest your inspiration. However, even when you are inspired, plan your user interface carefully—down to the most seamingly insignificant details. With large applications, document your look and feel in an application style guide.
When you’re struggling to find the right look and feel for a form or application, however, why reinvent the wheel? Software companies spend millions of dollars studying the look and feel of software. You can benefit from all this effort by looking through the software right on your machine. Take some time—perhaps now—to open up and browse through your favorite Windows 95 software applications. In general, what does the application look like? Look for consistent features. Are all the buttons the same size? If the application deals with large amounts of data, how is that data handled? Does the application use any Windows 95–style gadgets? What color scheme did they develop? What things do you like, and what do you dislike? What would you change? Be really choosey. Closely examine the details of these professionally developed applications.
Your applications should look as professional as commercial applications. The closer you get, however, the more your users will enjoy your application. You should at least choose a design concept and stick to it. Select your colors, form size, button size and location, frame style, and fonts. Don’t stray from the standard that you set for a particular project. If you don’t know what the look and feel should be, design with a simple version of the Windows 95–style look and feel.
Paradox comes with a plethora of objects and options. Browse through them and look at their many characteristics. Many people get caught up in a particular project and never explore the many visual features of Paradox. Spend some time studying the visual properties of objects. The objects from the toolbar tools that you can place in forms and reports are design objects. The better you know the design objects of Paradox, the better your applications will look. Make sure that you know what the properties do. For example, a field has several Run Time properties. What are the differences among Read Only, Tab Stop, and No Echo? Know the properties of design objects before you start programming in ObjectPAL.
A form in Paradox is used to present data, but it also doubles as the center of your application. A form has many objects that you can use to develop an application. It’s important that you have a good grasp of what these objects can do. A table frame is an object used to display multiple records on a form. A field is a multipurpose object that enables you to display a single value from a table. It also enables you to show users extra bits of information, calculated values, and other values not stored directly in the table. An object such as a button, field, or box is an item that the user interacts with to create events. The more you know about Paradox’s objects, the better your application will be.
A form stores the code for an application. For large applications, it is a good idea to break it into multiple forms or use libraries to store extra code. When you deliver your form, Paradox compiles it into what is actually a Windows DLL with a .FDL extension.
The main window in Paradox is the desktop. The desktop is the highest level of interaction with all Paradox objects. The desktop varies its size depending on your screen resolution. The desktop is also known as your application workspace. In ObjectPAL, there is an application variable type for manipulating Paradox’s application workspace.
Forms designed for one screen resolution don’t necessarily look good under a different resolution. If you will be porting applications from one machine to another, you should use the same resolution on both systems. (Also, be sure to use the same fonts on both systems.) If it’s impossible to use the same resolution, develop the form for the lowest common resolution—for example, VGA (640 × 480) rather than SVGA (800 × 600).
A form can consist of multiple pages, and an application can consist of multiple forms. It’s often difficult to decide when to add a page or start a new form. In general, think about adding a new page to the existing form first. If a new page won’t work, add a new form. Because every page of a form must be the same size, usually size dictates whether to use a new page or form.
When all the forms and pages are the same size, then I let the data model dictate whether to add a new page or a new form. The general rule is one data model per form. When the data model gets in the way, then start a new form. For example, in a typical invoicing system, you might link Orders to Customers. You could use one form with this data model and simply add pages until another data model is indicated. For example, suppose that you need to have a page or form for the user to browse through the Customer table. The preceding data model does not work because the Customer table is the second table in a one-to-one relationship; it is restricted by the Orders table. Common sense tells you to create a new form with a new data model; that is, a data model with just the Customer table in it.
A typical application consists of tables, indexes, forms, reports, queries, and possibly scripts or libraries. This presents a problem to the user: how to start up the application. The common practice for developers is to give the main form the same name as the directory that contains it. If you stick with this practice, the users of your Paradox applications will soon learn how to start them up.
Getting the Most out of Style Sheets
The prototyping of objects is a feature of Paradox that enables you to create great-looking and consistent forms and reports. This option enables you to save default settings, such as color, font information, ObjectPAL code, and so on. Use this feature to expedite the creation of consistent objects, complete with all the properties and ObjectPAL code. The following section discusses style sheets in general. If you need help changing the contents of the style sheet, consult Paradox’s manuals.
Style sheets are powerful tools for design development. You can maintain several different looks and switch among them before you create a design document (either a form or a report). You can set up several screen and report style sheet files (with different fonts, colors, frame styles, and so on) and save them to your working directory.
You can even use custom color schemes, which are saved as part of the style sheet file. You also can create your own color schemes that are independent of the Windows color palette. The possibilities are limitless.
Keep in mind, however, that many users are still bound to only 16 colors. If you have a better video card, remember that the custom colors you define probably will be dithered on lesser video cards. Therefore, it is recommended that you test your work on a standard 16-color VGA card. It’s also a good idea to test your application with at least three different Windows color schemes.
Tip: Design user interfaces using the default Windows color scheme. If you develop your applications using the default Windows color scheme, then your applications will look good with more of the predesigned Windows color schemes.
If you get into the habit of choosing a style sheet before you create the first form for a project, you guarantee a consistent look and feel for your entire application—with little or no effort.
On The Net: The following zip file contains several style sheets ready for you to use: http://www.prestwood.com/forums/paradox/books/official/files/style.zip If you have a style sheet to add to this zip file, email it along with a short description to mike@prestwood.com.
Everyone has his or her own technique for developing a form. This section explores one technique. Study this technique and use it to improve your own technique for developing forms. Following are the six steps of developing a form that I use:
Create the data model.
This includes gathering data components and business rules, and planning and creating the tables.
Prototype several forms.
Design several versions of one or two of the main forms of the application with the data models you created and the business rules you gathered in step 1. Let someone else decide which prototype form has the best look and feel. Create the rest of the forms.
Test the built-in behavior.
Run the form and see whether the basic data model and fields are what you need. Make sure that you use the application the way that the user will. For example, search for values, insert a new record, change, and delete records.
Add objects and design elements.
After you decide on the prototyped forms and test the built-in behavior, the next step is to add text objects, graphics, buttons, and so on, to get the overall visual effect you want.
Add ObjectPAL.
Decide what more you want an object to do and add the appropriate code.
Test.
Large companies thoroughly test their software, and so should you. There are many types of tests you can run, including unit testing, integration testing, and regression testing.
Step 1: Create the Data Model
You can use Visual Database Designer to create your tables and links visually. You can even save and load data model files (.DM files). Whether you’re working on forms, reports, or queries, all you do is draw lines between tables. The linking expert automatically does all the relational work for you by showing you how the tables can be linked. No matter how complex the relationship is, Paradox graphically displays the linked tables.
The first step in creating a form is to decide on a data model. The better you understand how the data model works and the theory behind relating tables, the easier it is for you to create forms and applications.
Step 2: Prototype Several Forms
Creating forms in Paradox is easy. Within a couple of hours, you could create nearly a dozen variations of a form. Design several versions of the main forms for your application and let someone else, such as the client, decide which prototype form he or she likes the look and feel of best.
When you prototype a form, set the form’s properties, decide on a style sheet, create the form using either the data model or an expert, decide whether you want the form to be a window or a dialog box, set the title of the form, and so on.
Set the form’s properties (see Figure 3-1). Get into the habit of setting the properties of a form whenever you create one. Give it a name, take the scroll bars off, and so on. Now is a good time to choose a look and feel for your application. Figure 3-1 shows the Window Style dialog box.
Figure 1: The Window Style dialog box
Step 3: Test the Built-In Behavior
Because Paradox has a tremendous amount of built-in functionality, exploring the built-in behavior of the form is important. Users often waste time because they don’t know the built-in behavior. Sometimes, the built-in behavior is different from what they assume it is. After programming for many hours, they finally give up and either call for support or post a message on the Internet, only to be told that the default behavior already does what they were trying to do. In other words, if you don’t know the default behavior, you might waste time duplicating it. Even worse, your added code may cause problems, prompting you to write more code to fix. This is a programming loop you must try to avoid.
Note: Paradox provides experts that generate code at the field level, in the form open, etc. It is a good idea to study the ObjectPAL generated by these experts.
Testing your form before you begin to add to it also gives you an overall sense of what you’re trying to accomplish. Developers often get caught up in one detail of an application and lose sight of the big picture. Use your forms the way your users will. Your applications will have a much better look and feel.
The next step is to add objects—calculated fields, lines, graphics, boxes used to contain fields (a wonderful way to set the tab order for a group of objects), and so on. You add more objects only after you thoroughly test the built-in behavior of your newly created form.
Step 4: Add Objects and Design Elements
When first developing a form, consider using the Snap To Grid option to help you quickly place many objects on a form in orderly positions. The grid consists of horizontal and vertical lines that help you place objects. You can show or hide the grid; you also can resize it. Use Snap To Grid when you first design a form. Doing so cuts down the time needed to design the form.
Step 5: Add ObjectPAL
If you have a detailed design specification, then the next step is to alter the default behavior of the objects to behave as specified. Before adding any code to alter or add to the built-in behavior, thoroughly test how your objects and design elements operate with the built-in behavior of Paradox. The next step is to decide what more you want the form to do. Do you want the form to automatically put values in fields? Do you want it to open another form? Do you want to add pull-down menus and a custom toolbar?
Whatever ObjectPAL you decide to add, develop in small steps and test as you go. If you add code and the code doesn’t work, take it out! I can’t tell you how many times I have talked to programmers who swear that the problem they have is a bug in Paradox and it turns out to be their overcoding. Often when faced with a task, you will experiment with code to see what happens. If you just keep adding code to your form in hopes of solving the problem, you will end up with a mess. Remember to remove code experiments. Also, remember to step back and remind yourself what you are trying to do, and try to think of different ways of accomplishing the same task.
Note: If you are already familiar with ObjectPAL, here is a tip. If, in experimentation, you use sleep(), doDefault,, or DisableDefault to overcome some odd or misunderstood behavior, do not leave the commands in your code. If using the command didn’t seem to make a difference, then take it out. Use commands only when they are called for. One great way to really learn the event model and the power of these and other commands is to experiment with adding them. Remember to take them out, however, if they do not do what you wanted.
If you really think you have found a bug in Paradox, then don’t waste any time on your complicated form. Instead, try to duplicate the problem on a brand new form with no extra code on it. Only after you have duplicated the problem on a new form should you notify Corel. I believe that you will find, more times than not, that the problem is not a bug in Paradox, however.
Step 6: Test
The final step in developing a form is to test your form as a whole. You’ll see whether you are done or need to go back to steps 4 and 5. You should test your ObjectPAL code as you go. In this step, you test the whole application, not its individual elements. Does the form behave the way you thought it would? Does it behave the way your users will expect it to? Does it integrate with the rest of the application?
Now that creating forms has been discussed in general abstract terms, the following section discusses specific design issues of creating forms.
Child Windows Versus Dialog Boxes
Put some thought into whether you want a form to be a child window or a dialog box. Forms that are child windows obey Microsoft’s Multiple Document Interface (MDI). The MDI, for example, dictates that when you maximize one child window, all child windows are maximized.
A temporary window that requests or provides information is a dialog box. Many dialog boxes present options from which you must choose before you can perform an action. Other dialog boxes display warnings or error messages. Some are even utilities, such as the Paradox Workbench that is available from Prestwood Software & Consulting (www.prestwood.net).
A modal dialog boxis a dialog box that the user can’t leave until he or she responds to it. In general, model dialog boxes are frustrating to the user and should be avoided. Reserve the use of model dialog boxes to situations when additional information is required to complete a command or when it is important to prevent any further interaction until satisfying a condition.
Note: If you leave the form as a child window to Paradox and hide the Paradox desktop, the child window hides with it. If you want to hide the Paradox desktop so that the form is the only visual object onscreen, you must define the form as a dialog box. Remember that a form is a dialog box only when it is opened in View Data mode. If you’re in Design Form mode, running the form isn’t the same as reopening it. You must reopen it.
Spicing Up Your Forms
Windows is a wonderful color graphics environment. With the early versions of Windows, most applications had white backgrounds with black letters. Microsoft added three-dimensional buttons to version 3.1 to improve the look. Now with Windows 95, applications have come to life visually with stunning three-dimensional schemes. Keep this in mind, because your users will demand a high degree of visual appeal from your database applications. Just remember not to overdo it; keep your applications looking professional.
Spicing Up Your Applications
UIObjects
are objects, such as circles, lines, fields, and buttons, that you can draw by using the toolbar. You can add pictures to spice up UIObjects. Use bitmaps whenever possible. Although small bitmaps are not part of the Windows 95 look and feel, many users consider them particularly attractive; they give your application a professional look. This illustration demonstrates adding graphics to buttons:
Illustration 1
Do Not Crowd a Form
Many users use Paradox to duplicate printed forms: applications, records, and so on. Your natural inclination might be to put all the fields on a single 8.5 × 11-inch page—just like the real form. Try to resist this temptation, because it causes problems with the user interface.
Consistency Is the Key to Creating Good-Looking Forms
Choose consistent colors when you create and place objects. If you choose a white background for your forms, stick to it. If you choose another color or a special color scheme, such as a Windows 95 look, stick to it. When you design forms, a good approach is to set your colors to the Windows default by using the Control Panel.
To achieve a good user interface, you need to be consistent. Make similar objects the same size. Buttons are especially noticeable; try to use only one or two sizes for them and locate them on the right or bottom side of the form. Use a consistent line width and frame style.
At the same time, limit the number of visual elements in your application. A good-looking application doesn’t have an abundance of colors or objects. Instead, good-looking applications use subtle design elements. Use patterns sparingly; only one or two styles for each application. When you select colors, feel free to choose as many as you need for the foreground, background, text, title, and user input—just be consistent. Realize, however, that just because your users have at least 16 colors, you don’t have to use every color on a single form or in a single application.
Just as Microsoft has found a look and feel it likes (the Windows 95/98 look), you should strive to find your own style. You can create several looks and switch among them with each project, or you can develop a single look; your users may soon recognize your applications. Keep in mind, however, that the data is more important than the flashy objects around it.
This section does not tell you how to use the data model; data model theory is discussed in Chapter 2, and it is assumed that you already know the basics of linking tables with the data model. Instead, this section points out some common pitfalls of the data model and table lookups with respect to forms.
Link the Correct Way
When using referential integrity, make sure that you link from the master to the detail. If you accidentally link from the detail to the master, the data model will attempt to update the child table before updating the master table; this causes the error message Master Record missing.
Do Not Hard-Code Table Lookups
When you hard-code a table lookup, you specify the drive, path, and table filename. As discussed in Chapter 2, aliases are not allowed on table lookups. This, unfortunately, limits the usefulness of table lookups. If your data needs to be portable, then put the table lookups in the same directory as the main data or a subdirectory below it. This second technique is called relative directory addressing (RDA). This enables you to move your entire data directory (along with its subdirectories) to a different location.
Many users have trouble understanding calculated fields. For this reason, and so that you don’t try to duplicate this functionality by using ObjectPAL, this next section explores how to use special, summary, and calculated fields.
Using Special or Calculated Fields
To use a special or calculated field, select the field into which you want the value to go, inspect its properties, and choose Define Field. You can use the tools in the Define Field Object dialog box to set up a special or calculated field.
When you define a field object, you attach it to data from a table. For example, you define a field object in a form as a field in a table. You cannot define calculated fields to a field in a table. Do not confuse defining with binding. You bind or associate an object such as a table frame or multirecord object (MRO) with a table, whereas you define a field.
Special Fields and Summary Fields
A special field is a field, placed in a design document, that contains information about a table or design. These fields are predefined by Paradox, such as Now and Table Name. Table 3-1 describes special fields, Table 3-2 describes special table fields, and Table 3-3 describes the summary fields.
Field
Description
Now
Displays the current running time in the field. This is an excellent and easy way to add a clock to your application. Because you can’t define a field to a table and also use it as a special Now field, use the time() method via ObjectPAL to time-stamp a record or use the TimeStamp field type.
Today
Displays the current date in the field.
TimeStamp
Displays the current time and date in the field.
Page Number
Displays the current page number of the form.
Number of Pages
Displays the total number of pages in the current form.
Table 1: Special Fields
Field
Description
Table Name
Displays the name of the table in the field. Table Name is particularly useful in reports.
Record Number
Displays the current record number in the field. Using a table’s record number is particularly useful for autonumbering records in forms and reports when you don’t need to store the number with the table. Record Number obeys restricted views. That is, if the number of records is restricted by the data model, Record Number reflects this and starts numbering at 1. This makes it useful for autonumbering items in a typical invoicing system.
Number of Records
Displays the total number of restricted records.
Number of Fields
Displays the number of fields in the table.
Table 2: Special Table Fields
Field
Description
Sum
Adds all the values.
Count
Displays a count of all the records.
Min
Displays the smallest value for this field in the table.
Max
Displays the largest value for this field in the table.
Avg
Displays the average value for this field in the table.
Std
Displays the standard deviation of the values in the set.
Var
Displays the statistical variance of the values in the set.
Table 3: Summary Fields
Example of Autoincrementing a Restricted View
Suppose that you wish to number the detail records in a typical invoicing system. To do this, you do not need ObjectPAL. The special table field Record Number can handle the task.
Step By Step
Launch Paradox, and set your working directory to the Paradox’s sample directory.
Select File | New | Form and use the Data Model option to link ORDERS.DB to LINEITEM.DB in a 1:M relationship. Select OK.
At the Design Layout screen, select By Rows under the Field Layout section in the Layout tab, and select OK.
Add a column to the detail table frame by clicking below row 1 until the column is selected. Then press the insert key. Your form should now look similar to Figure 3-2.
Figure 2: Adding a column to a table frame
To display the Define Field Object dialog box for the newly added column, select the undefined field of the column you added in step 4. Right-click (or press F6) to inspect the field. Select Define Field.
Select the drop-down arrow of the LINEITEM.DB table and then select "". Select OK.
Label the column Item Number if you want, and run the form. Optionally, you can change the format of the field to integer. The form, depicted here, shows the use of a table field for the line item in the first column.
Illustration 2
Save the form as REC-NO.FSL.
Note: If you had any problems with this example (or any example in this book), you can download the completed files from the Internet at http://www.prestwood.com/forums/paradox/books/official/files.
Analysis
The first column is numbered 1 through however many records there are in the restricted view. The restricted view is determined by the table relationships set up in the data model. This operation is built into Paradox. You could do this same operation in ObjectPAL, but with difficulty.
Tip: Before you code in ObjectPAL, ask yourself two questions. Does Paradox already do this? Is there a better and easier way? Remember, simple solutions for simple problems.
You also can use the Record Number table field with reports—for example, when you want the records of a report to be numbered. Special and summary fields have many uses, so make sure that you know what all these field types do. The Now special field is particularly useful. To put a clock on a form, simply place an undefined field on the form and define it as the Now special field type. Voila! In an instant, you have created a running clock on your form.
Calculated fields use the Calculated panel of the Define Field Object dialog box to set up a user-defined formula or to display concatenated strings. When you combine two or more alphanumeric values, you concatenate them. An operator is a symbol that represents an operation to be performed on a value or values. For example, the + operator represents addition, and the * operator represents multiplication. The arithmetic operators in ObjectPAL are +, -, *, /, and ( ). Use these operators to construct mathematical expressions in queries and calculated fields. To concatenate two or more alphanumeric values in a calculated field (or ObjectPAL), for example, use the + operator. For example, the following formula
1: City.value + ", " + State.value
concatenates three strings to form a value, such as
1: Milpitas, CA
In addition to arithmetic operators, you can use in a calculated field any expression that returns a single value. This includes any ObjectPAL statement that returns a single value. Although you have not formally started your study of ObjectPAL, here are some fairly self-explanatory, single-command expressions you can use in a calculated field:
Proofer: no alpha necessary in table. Mark
startUpDir()
privDir()
workingDir()
windowsDir()
windowsSystemDir()
isToolBarShowing()
getMouseScreenPosition()
version()
isDir("C:\\DOS")
fieldName1.value + fieldName2.value
Following are some combination-method expressions you can use in a calculated field:
You can use the iif (immediate if) statement in both calculated fields and ObjectPAL to make decisions. With an iif statement, you can in essence say, "If the following expression is true, this field’s value is A. Otherwise, this field’s value is B."
Tip: If you ever have a calculated field on a form not update when you think it should, then you can use the ObjectPAL method forceRefresh() to make the calculated field display the correct values. This can occur, for example, when you update a field involved with a calculated field using a TCursor.
Special fields, special table fields, summary fields, and calculated fields are important to the ObjectPAL programmer. Many times, tasks are easier to accomplish with these fields than through ObjectPAL.
In addition to designing and creating tables, designing good forms makes your application more professional. Forms are the backbone of your application. In fact, in Paradox, forms are your application. The better you are at designing forms, the better your applications turn out.
Paradox
Print This
Tags:
