Chapter 13

Forms Design I

In this chapter, you will learn about the following facets of building forms:

• Working with data blocks and frames
• Working with text items
• Creating LOVs and editors

To create Form Builder applications in Developer/2000, you must understand the components that work together on a finished form. The foundation of most forms is data blocks, which provide the link between the form and the source of the data being displayed. In this chapter, you will learn quite a bit about data blocks, as well as the nondata version of form blocks: control blocks. You will also be introduced to the components of the Property Palette, where you specify how every object on a form will look and function. Once you are familiar with navigating the Property Palette, you will learn about specific groups of properties important for form development: properties that control the appearance and behavior of data blocks, the frames surrounding data blocks, and control blocks, among others. Next you will learn about text items—the objects on a form that enable the user to see and edit text, numbers, dates, or long data. You will learn about text item properties, including those you can use to enforce data-quality standards at the point of input. You will see how to create tooltips and hints for your users. Finally, you will practice creating Lists of Values (LOVs) and editors on your forms to enhance productivity.

Overall, the contents of this chapter comprise about 13 percent of OCP Exam 3 test content.

In this section, you will cover the following points related to working with data blocks and frames:

• Property Palette components
• Manipulating properties
• Controlling the behavior of data blocks
• Controlling frame properties
• Creating blocks that do not correspond to a database object
• Deleting data blocks and their components

In the previous chapter you used wizards to effect changes on a variety of objects and properties—the items included in data blocks, the relationships between blocks, the items displayed on a canvas, and so forth. While the wizards are very helpful for certain tasks, they give you access to only a small portion of the properties you can change. This section will introduce the Property Palette, which gives you much greater control over the objects you create. You will learn how the Property Palette works, how to use it to control the behavior of data blocks, and how to control frame properties with it. Building on this knowledge, you will learn about blocks that do not correspond directly to a database, and you will create a block of this type. Rounding out this section, you will learn how to delete data blocks and their components in two different ways, observing the characteristics of each approach as you experiment.

The Property Palette provides complete control over many facets of your objects. Using it efficiently requires understanding its components so you can select the best approach to setting the parameters you need.

To start learning about the Property Palette, start Form Builder and open the file containing your sample application from Chapter 12. Then open the Data Blocks node and double-click on the DEPARTMENT data block to open its Property Palette. You will see a window that looks similar to Figure 13-1.

The toolbar contains buttons giving convenient access to functions relevant to setting properties: property copy and paste, property add and delete, and property-class create and inherit. You will also see a button with a shape like an upside-down "U", which determines what properties are shown when you use a single Property Palette to show properties for multiple objects. When the "U" is upside down (the default setting), the Property Palette is in Intersection mode and shows only the properties that are common among all the objects you have selected. Clicking the button switches the Property Palette to Union mode, in which every property related to the selected items is displayed, even if a property relates to only a single item. In either mode, a shared property that has the same value for all selected objects will show that value, but if the value is not the same for every selected object, the property will display "*****" instead of a value.

The next toolbar button, labeled Freeze/Unfreeze, helps work around a feature of the Property Palette that can be annoying in certain circumstances. Usually the Palette changes its contents each time you select a different object, so that the current object’s properties are displayed. This is generally a convenience. However, when you have more than one Property Palette open, all of the Palettes will change their contents each time you select a new object. The Freeze/Unfreeze button solves this by forcing a Property Palette to continue showing properties for its current object, regardless of what objects you select from that point on. To see this in action, open your sample application. Open the Data Blocks node so you can see the DEPARTMENT and EMPLOYEE data blocks. Then open a Property Palette for the DEPARTMENT data block by double-clicking on its icon, or by right-clicking on it and selecting Property Palette from the Layout Wizard. Open a second Property Palette by holding down the shift key and double-clicking on the icon for the EMPLOYEE data block. The second Property Palette will open in exactly the same position as the first one, so you will need to move or resize the second Property Palette in order to see both. Click once again on the DEPARTMENT data block. You will see that both Property Palettes shift their display to show properties for that data block. Click on the EMPLOYEE data block, or any other object, and you will see that both Property Palettes continue to follow your selection in lockstep. To solve this, click on the DEPARTMENT data block, and then in the first Property Palette you opened, click on the Freeze/Unfreeze button. This will force the Palette to keep its focus on the DEPARTMENT data block. Click on other objects in the Object Navigator, and you will see that the second Property Palette changes its contents to follow your selections, while the first Palette continues displaying properties for the DEPARTMENT data block. Click on the EMPLOYEE data block, and then in the second Property Palette you opened, click on the Freeze/Unfreeze button. This will force the second Property Palette to keep its focus on the EMPLOYEE data block. Click on other objects in the Object Navigator. You will see that no matter what item you select, both Property Palettes remain on their "frozen" objects.

To the right of the toolbar is a field labeled Find. This search field is very handy, because it makes the Property Palette quickly jump to specific properties. If the group containing the matching property is closed, the Find field will even open it up for you. For instance, if you want to change the sort order of the data returned by a data block, you can jump to that property by just typing the letter O in the data block’s Property Palette’s Find field. The focus will immediately move to the order by clause property.

Located beneath the toolbar, the context bar identifies which object is currently having its properties displayed by the Property Palette. The first text on the context bar line identifies the type of object: form module, trigger, data block, item, relation, etc. (When you test this on your own system, remember to unfreeze the Property Palette first.) The object type is followed by a colon and then the name of the selected object.

The main portion of the Property Palette, of course, is the property list. This two-column display shows the property names in the left column, and their current values in the right column. The properties are grouped by category, and a + in front of a category name indicates that the category is collapsed and not displaying its properties, while a – in front of a category name means that the category is expanded and that the properties within that category are all visible. You can toggle between these two states on a category-by-category basis by clicking on the + or – in front of each category name. Each object type in your application has different properties, and the Property Palette is smart enough to remember which property categories you like to have open and closed for each type of object.

The Property Palette contains several different types of value fields. As you move from property to property, you will encounter the following field types in the Property Palette’s value column:

• Alphanumeric fields for typing values
• Fields containing a button labeled More, which opens a dialog box for setting values
• Fields with a button showing an ellipsis (…), which opens a window for entering and editing lengthy text like comments or where clauses
• Drop-down lists of fixed, predefined values (such as Yes/No fields, or a data block’s fixed Navigation Style options of Same Record, Change Record, and Change Data Block)
• Lists of Values (LOVs) containing lists whose contents can change (such as a canvas frame’s Layout Data Block property, whose list will show whatever data blocks your application has)

You can change properties simply by clicking on the value field for the desired property and either typing in the correct value, selecting it from a list, or specifying it in a dialog box. For properties that have lists, you can iterate through the choices in the list by double-clicking on the property name. This can be particularly handy for Yes/No properties.

You can compare the properties of two or more objects by selecting all of the items you want to compare, and then perusing the Property Palette. As long as you are in the Property Palette’s default Intersection display mode, the Palette will only show properties that are common among all of the selected objects. Properties having the same value in all selected objects will show the shared value, while properties that do not have the same value will display ***** for that property instead of a value. When you are showing the properties for multiple objects in a single Palette, any property you change will be changed in all of the selected objects, overwriting whatever prior settings the objects had for that property.

If you want to contrast the properties for more than one object, you can open multiple Palettes by shift-double-clicking on the second and subsequent object icons.

The Property Palette’s copy and paste functions operate just as you would expect for individual properties: you select the property that contains the value you want to copy, click on the Copy Properties button, move to the property to which you would like to copy the value, click on the Paste Properties button, and the value from the source property is written into the destination property. Now for the interesting information about copying and pasting:

• You can select multiple properties to copy all at once, using the shift and ctrl keys along with the mouse.
• If any of the properties you selected are displaying *****—meaning your Property Palette is reflecting multiple objects, and some of those objects’ shared properties do not have the same value—the Copy command will ignore those properties. The Copy command will only copy values from properties whose values are the same among all the source objects.
• The destination object does not need to be the same type as the source object. For instance, you can copy the Visual Attribute Group properties from a data block to a canvas. The Paste command is flexible enough to only paste the properties that are appropriate for the destination object.

The properties for a data block are divided into nine categories: General, Navigation, Records, Database, Advanced Database, Scrollbar, Font & Color, Character Mode, and International. From a developer’s perspective, you can divide these categories into three main groups:

• General properties This is where you can change the data block’s name, subclass the data block beneath another object or property class, and enter comments about the data block. The General category offers similar properties for all Form Builder objects.
• Behavior properties This includes the Navigation group, Records group, Database group, and Advanced Database group.
• Appearance properties This includes the Scrollbar group, Font & Color group, Character Mode group, and International group.

The behavior properties are very important to developers. Several deserve special attention. The Query Array Size property controls how many records will be fetched from the database at a time. The Number of Records Buffered property specifies how many records the Forms Runtime program will keep in the client computer’s memory when the form is run (records beyond this quantity are stored in a temporary disk file on the client). Increasing the number improves client performance but requires more RAM; decreasing it saves client RAM. The default value for Number of Records Displayed is + 3. The Query Allowed property determines whether the user (or application code) can execute a query in this data block. The where clause allows you to enter filtering criteria to limit the types of records returned. The order by clause lets you select how the returned data should be sorted. The Insert/Update/Delete Allowed property fills out the C.R.U.D. (Create/Read/Update/Delete) control of your block. (C.R.U.D. is not an Oracle term.) The Update Changed Columns Only property specifies that when the user changes an existing record, the update command sent to the server only includes the fields that were changed. While that may seem like a good idea in general, it forces Developer/2000 to reparse the update statement for every record being updated, which can degrade performance. It is useful when the record contains LONG values that are not likely to be updated, or if the user is likely to be updating the same one or two columns, or if you have column-specific triggers in your database that you do not want firing unnecessarily. The DML Array Size property controls the number of records that will be sent to the server in a batch. Increasing the number reduces network traffic and therefore improves system-wide performance, but requires more memory on the client computer. Since this command creates batch processing, it forces the Update Changed Columns Only property to No regardless of the property’s set value. This property is ignored if the block includes a LONG RAW item.

There are a number of properties that will be of particular interest as you work with frames on your application’s canvases. Frame Title Alignment lets you select the horizontal position of your frame title within the top border of the frame. The Number of Records Displayed property is a value that you initially specify while running the Layout Wizard. If you want to change it later, this is the property to use. You can also change this value by rerunning the Layout Wizard on a frame. The Distance Between Records property is also specified—and usually ignored—while running the Layout Wizard. If you decide you want a little more space between rows, you can make that modification using this property. You can also change this value by re-running the Layout Wizard on a frame. The Bevel property lets you select from five different types of frame borders. The choices are Raised, Lowered, None, Inset (the default), and Outset. Figure 13-2 shows how each bevel type looks. The Frame Title Font & Color group property gives you control over the frame title’s appearance—its font, size, spacing, and color, among other things. In order to standardize these frame appearance properties across your application, you may want to specify them as a Visual Attribute (one of the nodes under Forms in the Object Navigator) and then assign that visual attribute to the appropriate frames.

So far, all the blocks you have created have been data blocks, which serve to provide a data link between a form and a database. There is another type of block—one that is not associated with a database object. This is called a control block. The items in a control block are not related to database columns. Instead, it contains either controls such as buttons, or a group of items with single values, such as calculated subtotals.

Unlike data blocks, control blocks have a two-part creation process: create the control block, and then manually create the items that go in the block. To get a taste of how this is done, open Form Builder. Within the Object Navigator form module where you wish to create the control block, click on the Data Blocks node. Start the process of creating a new block by clicking on the Create button, or executing the Navigator | Create command. From the New Data Block dialog box that appears, select the Build a new data block manually option, and then click on the OK button. You will see a new block appear under your Data Blocks node. Double-click on the icon for the new block to open its Property Palette. Under the Database node in the Property Palette, change the property named Database Data Block to No. Change the block’s name (under the General node) to DEPARTMENT_EXIT.

You now have an empty control block. You will place within it a single item: a button that the user may click to exit a form. In the Object Navigator, click on the Items subnode beneath the DEPARTMENT_EXIT block. Click on the Create button, or execute the Navigator | Create command. In the new item’s Property Palette, change the item’s Name property to EXIT_BUTTON. While in the General property node, change the Item Type to Push Button. Under the Functional node, changed the Label value to Exit Form. Under the Physical node, change the Canvas property to the canvas containing your Department data block.

You now have a control item on your DEPARTMENT canvas. But the item doesn’t do anything yet; it has no code beneath it. To add code, open the canvas containing your Department data block in the Layout Editor. Drag the control button from the top-left corner of the canvas to a position centered beneath the Department data block. Right-click on the button and select SmartTriggers from the context menu that appears. In the list of SmartTriggers, select WHEN-BUTTON-PRESSED. Form Builder will open the PL/SQL Editor. Enter this code to give the button its functionality:

BEGIN
EXIT_FORM (ASK_COMMIT, NO_ROLLBACK);
END;

Run the form. When it opens in the Forms Runtime program, click on your new Exit Form button to see it perform.

There are two ways you can delete data blocks and data block components: from the Object Navigator, and from the Layout Editor. Each has as slightly different impact. The important thing to know is how closely linked Object Navigator objects are with those in the Layout Editor. It will probably not surprise you to find out that deleting an object in the Object Navigator will cause that object to be removed from any canvas in which it was used. Not so obvious, however, is that the reverse is also true: deleting an object from a canvas in the Layout Editor will remove that object from the Object Navigator as well.

To see this demonstrated, open the Form Builder and your sample project from this chapter, if it is not already open. If it is already open, save it now. This is important, because in this exercise you will be deleting items that cannot be undeleted. Then open the Data Blocks node so you can see the data blocks displayed. Open the Canvases node and double-click on the canvas that displays your DEPARTMENT data block. Arrange the Object Navigator window and Layout Editor window so you can see the contents of both simultaneously. In the Object Navigator, click on the DEPARTMENT data block and press the Delete key to delete it. Answer Yes to the confirmation prompt. Notice what happens on the canvas in the Layout Editor. The frame that contained your DEPARTMENT data block is now empty. The data block and its items are gone, while the frame and the frame title are still there.

Open the Edit menu. Notice that the Undo command is not available. When you delete a data block or data block component from the Object Navigator, it cannot be undone with the Undo command. Now use the File | Revert command to revert your sample project to the state it was in before you deleted the data block. Your sample application is now exactly as it was before you deleted any objects.

Now it is time to see what happens when you delete data block items from the Layout Editor. Once again open the Data Blocks node. Then click on the + next to the DEPARTMENT data block so you can view its components, and click on the + next to the Items subnode so you can see the DEPARTMENT_ID and DEPARTMENT_NAME items. Open the Canvases node, then open the canvas containing your DEPARTMENT data block and position the windows again, if necessary, so you can see the contents of both the Object Navigator and the Layout Editor. In the Layout Editor, select the entire DEPARTMENT data block by clicking outside one of the block’s corners and dragging the mouse to the opposite corner. You should see the entire block display selection marks, including the items, titles, and scroll bar within it. Notice that in the Object Navigator, several items are selected: the DEPARTMENT_ID and DEPARTMENT_NAME items in the data block, as well as the frame in your canvas that holds those items. Now delete the selected items in the Layout Editor by pressing the Delete key. Notice that this time there are differences in the result. In the Layout Editor, everything has been deleted except the scroll bar: the frame and its boilerplate text are gone, as well as the items the frame contained. In the Object Navigator, you can see that the items are also gone from the DEPARTMENT data block’s Items subnode. The data block itself is still there as an empty data structure, buts its triggers and relations remain intact. Now open the Edit menu. Notice that the Undo command is available this time. When you delete a data block or data block component from the Layout Editor, you can get it back if you immediately issue an Edit | Undo command. Use the File | Revert command now to revert your sample project to the state it was in before you deleted the data block.

In this section, you will cover the following points about working with text items:

• Introduction to text items
• Modifying a text item’s appearance
• Controlling the data in a text item
• Modifying the navigational behavior of a text item
• Enhancing the relationship between a text item and a database
• Modifying the functionality of a text item
• Including help messages in your applications

This section covers the most ubiquitous part of any form: text items. You will learn what text items are, and how they differ from display items. You will learn which properties are available to control the appearance of data within text items, and you will learn more about Visual Attribute Groups, which enable you to specify and store named sets of appearance properties that can be referred to by objects in your forms. This helps ensure that similar items look identical throughout your application, and it can save you an immense amount of time if you need to make application-wide changes to appearance later, because you simply change the appropriate Visual Attribute Groups. Next you will learn about the properties that give you control over what the users can, or must, enter. After that, you will be introduced to the properties that affect how users can move around your application, and then you will see which properties control how your Form Builder application interacts with a database. Next, you will learn about properties that affect the scope of queries, along with properties determining what items the user can insert or update. Following this, you will discover properties that control how text items get their value, whether they hide data entered by the user, and whether they are available for user interaction. Finally, you will learn about properties you can use to add user hints and tooltips to your application.

Form Builder uses the term text item to describe any control on your form that displays text, numbers, dates, or long data, and allows the data to be edited by the user. For instance, the fields that display your database items are text items. A text item differs from a display item in that the latter does not allow the user to change the data shown. A text item can be either single-line—the type used to display most database data—or multiple-line, which responds to the enter key by creating another line of text, instead of moving to the next item.

Since a text item is all about displaying data, it’s important to understand how to control the appearance of the data it displays. You can access the appearance-oriented properties by opening your canvas in the Layout Editor, selecting the text item whose appearance you would like to change, and opening that item’s Property Palette. Table 13-1 contains a number of the more relevant properties.

You undoubtedly noticed that Table 13-1 mentions the Visual Attribute Group twice. This handy feature allows you to create named groups of visual properties—font, colors, and fill, among other things—and then apply those properties to your forms. This feature is similar to the style sheets used in many word processors. If you change any of the default item appearance properties in your forms, it makes sense to use a Visual Attribute Group to do it. That way you can later modify the display properties in a single, centralized location, and have those modifications automatically propagate throughout your forms.

While controlling the appearance of a text item is important, the content of the data is even more important. Table 13-2 shows properties that give you control over what the users can, or must, enter.

To use the current date as a value in a text item property, set the Initial Value property to $$DATE$$. To use the current date and time, set it to $$DATETIME$$.

Once you have taken care of the quality of data the user enters, you can focus on the ease with which they can move around the application. Table 13-3 shows the properties you can employ that will help in this endeavor.

This section identifies properties that allow you to exert greater control over how your Form Builder application interacts with a database. There are properties that limit or expand the scope of queries users can perform, as well as properties to specify what items the user can insert or update, and under what conditions. Table 13-4 lists each of these properties in order and describes their purpose.

There are quite a few properties available that enable you to modify a text item’s functionality. These properties control how a text item gets its value, whether it displays data as the user enters it, and whether the item is active in the first place. Table 13-5 lists these properties and describes each one.

Form Builder provides properties making it very easy to add helpful information for your users to see as they move from item to item. The helpful information can take two different forms: hints and tooltips. A hint displays in the message line (the first line of the two-line area called the console, at the bottom of the form display) when the user enters a particular text item. A tooltip displays adjacent to the mouse pointer when the pointer is hovering over a text item. Table 13-6 lists the properties that provide you with these capabilities.

In this section, you will cover the following points about creating LOVs and editors:

• Introduction to LOVs and editors
• Creating LOVs
• Creating editors

This section covers two features which can make the forms you create much easier for users to work with: Lists of Values and editors. A List of Values (LOV) is a pop-up window that displays a series of choices from which the user selects. LOVs incorporate a feature called autoreduction that makes it possible for users to select the list item they want with an absolute minimum of keystrokes, which can save a substantial amount of time in high-volume production environments. In this section, you will create a new form and incorporate your own LOV into the form. After learning about LOVs, you will move on to editors. An editor is a dialog box that appears when the user is in a text item. You will see how to create custom editors that incorporate your own titles, visual attributes, and even a different editing program, if you wish.

A List of Values (LOV) is a specific type of pick list used in Developer/2000. It consists of a pop-up window that displays a series of choices relevant to the operation or text item from which it was called. The LOV window is modal, so the user has to either make a selection or dismiss the list. A sample LOV window is depicted in Figure 13-3, which shows the LOV of available triggers you would see if you created a new trigger from the Object Navigator.

One very useful feature in the LOV window is autoreduction, which filters the list’s entries in real time as the user enters characters to identify the desired item. While many word processors offer a similar-sounding feature for operations like font selection, Developer/2000’s is smarter: if the list includes items whose names have many identical characters, the user only needs to type the characters that differentiate one item from the next.

For example, consider a situation where you want to create a trigger for a KEY-DOWN event. (This book will cover triggers later, so just read along for now—don’t try to follow this as an exercise.) To do this you would click on the Triggers node in your module and then invoke the Create procedure. You would immediately be presented with a list of the triggers available in Form Builder, as you saw in Figure 13-3. Since you want a KEY-DOWN trigger, you could type a k to reduce the list to only the items that start with "K." The result of this action is depicted in Figure 13-4. The only items showing are those that start with the same letter: "K." In fact, they all start with the same word: "KEY," followed by a hyphen. All you need to do next is identify which key you want; you do not need to type the "EY-" that would be required in, for instance, a font list. So you could type a letter d, and the list would diminish to only those values whose second word started with "D." This is depicted in Figure 13-5. To select from that list, you would only need to type a letter o, and the list shortens to a single entry: the KEY-DOWN trigger, as shown in Figure 13-6. With only three keystrokes, you could select the desired trigger from a list of over one hundred potential triggers.

You can also search an LOV for strings that occur anywhere within the values, not just at their start. For instance, if you wanted to create a trigger that fires when an item is changed but cannot remember the exact name of the trigger, you can type the word update after the "%" in the Find field and click the Find button. The list of triggers will be filtered to show only the values that have "update" somewhere within their names, as shown in Figure 13-7. This same versatile functionality is available in LOVs you create for your users, enabling them to find people, products, or anything else quickly and easily.

It is quite easy to create an LOV and use it in your forms. In this section, you will go through the steps of creating an LOV, configuring its properties, and assigning it to an item on a form. You will create an Employee form and design the Department ID field so it can be filled in from an LOV.

You will start by creating a new data block to get data from the EMPLOYEE table. (If you use the existing EMPLOYEE data block in a new canvas, it will be removed from the DEPARTMENT canvas where it already resides.) You will then create an LOV for DEPARTMENT data. Next, you will create a new canvas to display records from the EMPLOYEE data block. After testing your new canvas by running it in the Forms Runtime program, you will return to the Layout Editor and attach the DEPARTMENT LOV to the EMPLOYEE canvas. You will then run the Employee form again and see how it allows users to select a department by name and have the appropriate department number appear in the employee’s record.

Using the Data Block Wizard, create a new data block. Base it on the EMPLOYEE table, and include all of that table’s columns. Do not establish any relationships for the data block, and when the Data Block Wizard asks if you would like it to proceed to the Layout Wizard, tell it to just create the data block. Once the new data block has been created, change its name to EMPLOYEE_2. In the Object Navigator, select the LOVs node and then click on the Create button. In the New LOV dialog box, ensure that the choice New Record Group Based on the Query below… is selected. Then enter the following code as the source query for the LOV:

SELECT DEPARTMENT_ID, DEPARTMENT_NAME
FROM DEPARTMENT
ORDER BY DEPARTMENT_NAME

Click on the OK button to complete the procedure. Then open the Property Palette for the new LOV, and change its name to DEPARTMENT_LOV. Navigate to the LOV’s Functional properties group, and open the dialog box for Column Mapping properties. The dialog box should look like Figure 13-8. For the DEPARTMENT_ID column name, enter a Return Item property of EMPLOYEE_2.DEPARTMENT_ID. This specifies the destination into which the LOV will place the DEPARTMENT_ID value of whatever department record the user selects. Then enter a display width of 0, which will cause DEPARTMENT_ID to become a hidden column. As a result, the LOV will display only department names. Click on the OK button to close the dialog box. In the Object Navigator, you will see that a record group has automatically been created under the Record Groups node to supply data to your new LOV. Change the record group’s name to DEPARTMENT_LOV.

Now you have an LOV, but it isn’t yet attached to a form. To do that, navigate to the Object Navigator’s Canvases node and change the name of your existing canvas to DEPARTMENT. Then start the Layout Wizard to create a new canvas. Specify (New Canvas) for the canvas name, and move the Available Items into the Displayed Items area in the following order: LAST_NAME, FIRST_NAME, EMPLOYEE_ID, HIRE_DATE, SALARY, DEPARTMENT_ID. Specify a layout style of Form and a frame title of Employee. When the finished canvas is displayed in the Layout Editor, click on the background of the form to select the entire canvas, open the Property Palette (function key f4 is a shortcut to do this), and change the new canvas’s name to EMPLOYEE.

Continue by selecting the DEPARTMENT_ID item. In the Property Palette, set the item’s List of Values property to DEPARTMENT_LOV. Move farther down the Property Palette to the property named Validate from List, and set that property to Yes. Then run your form. Use the Next Block button on the toolbar to move from the DEPARTMENT form to the EMPLOYEE form. Enter the following values in a new record: Last Name Carilla, First Name Bianca, Employee ID 1011, Hire Date 10–MAY-1999, Salary 65000.

When you move into the Department ID item, notice that the bottom line in the console displays the indicator "List of Values." This is your clue that you can enter data into this item using a list, as well as by typing directly. To see the LOV, press function key f9 or use the menu command Edit | Display List. You should see an LOV appear that looks like the one shown in Figure 13-9. Select the Quality Assurance department either by typing Q and clicking on the OK button, or by double-clicking on the Quality Assurance value in the list. When you do, you will see the Quality Assurance department’s ID automatically appear in the item. Save the record by clicking on the Save button, and then exit out of the Forms Runtime program.

Once you have returned to Form Builder, close the Layout Editor and then open the Property Palette for the LOV named DEPARTMENT_LOV. Table 13-7 shows a number of properties you can use to tailor the look and feel of the LOV.

In Developer/2000, an editor is a dialog box that can appear when the user is in a text item. In addition to giving the user more space in which to type text, an editor provides Find and Replace functions that can be useful when modifying large blocks of text. You can open an editor any time your cursor is in a character, number, or date/time field by pressing ctrl-e (remember that in Developer/2000 the ctrl-key commands are case sensitive, so this command will work only if your caps lock key is off). This keystroke command will produce an editor window similar to the one shown in Figure 13-10. Clicking on the Search button takes you to the Search/Replace dialog box shown in Figure 13-11.

Since you can call up an editor any time already, why create your own? Customization. Designing your own editor allows you to specify what editing program is opened for the user, as well as customize the editor window’s size, shape, title, and appearance.

Editor windows are most useful for character fields that will hold large amounts of text. The sample application you have created for this unit does not have any fields of this type, so to learn how to make a custom editor you will create one for the DEPARTMENT_NAME item. In Object Navigator, select the Editors node and then click on the Create button. Open the Property Palette for the new editor. Change the editor’s Name property to DEPARTMENT_NAME_EDITOR. Change the Title property to Department Name Editor, and the Bottom Title property to Sample Bottom Title. Change the X Position property to 100, the Y Position property to 25, the Width to 400 and the Height to 300. Change the Show Vertical Scroll Bar property to Yes. Then open your DEPARTMENT canvas and display the Property Palette for the DEPARTMENT_NAME item. Change the item’s Editor property to DEPARTMENT_NAME_EDITOR. Then run your application. When the DEPARTMENT form opens in the Forms Runtime program, populate the form using the Execute Query button. Then move to a Department Name item, and press ctrl-e to invoke to editor. The editor window that appears should look very similar to Figure 13-12. When you are finished, close the editor window, exit from the Forms Runtime program, and return to Form Builder.

If you just want your user to have a more flexible editing window and do not care about custom titles or visual attributes, you can tell Developer/2000 to use the default system editor (Notepad in Windows systems) instead of Developer’s internal editor. You can do this by opening the canvas in Layout Editor, selecting the relevant text item, and changing its Editor property to SYSTEM_EDITOR.

In this chapter, you have covered quite a bit of information about Forms design. You began by learning about the components of the Property Palette, which consist of the toolbar, context bar, and property List. The toolbar contains buttons giving convenient access to functions relevant to setting properties: property copy and paste, property add and delete, and property-class create and inherit. It also provides buttons that control whether a Property Palette invoked for multiple objects shows only the properties those objects have in common (intersection mode), or shows all of the properties for all objects (union mode). The next Property Palette toolbar button, labeled Freeze/Unfreeze, forces the Palette to continue showing properties for its current object, regardless of what objects you select from that point on. To the right of that button is a field labeled Find that lets you quickly jump to specific properties in the Property Palette.

Beneath the toolbar is the context bar, which identifies the object whose properties are currently being displayed by the Property Palette. Below that is the property list, the main portion of the Property Palette. The property list arranges properties into groups and provides the familiar + or – in front of each group name to open or close the group’s properties. Each object type in your application has different properties, and the Property Palette remembers which property categories you like to have open and closed for each type of object.

Next you learned how to manipulate properties using the Property Palette. The Property Palette contains several different types of value fields: alphanumeric fields for typing values, fields containing a button labeled More… that opens a dialog box for setting values, fields with a button showing an ellipsis (…) that opens a window for entering and editing lengthy text such as comments or where clauses, pop-up lists of predefined values, and Lists of Values (LOVs) containing lists whose contents can change. You can compare the properties of two or more objects by selecting all of the items you want to compare: shift-clicking allows you to quickly select contiguous groups of objects, and ctrl-clicking lets you select noncontiguous objects. When a Property Palette is displaying properties for multiple objects, it displays ***** for properties that do not have the same value for all the objects selected. You can change the properties for multiple objects simultaneously by selecting all the objects and then changing the desired property in the Property Palette. The Property Palette offers copy and paste functions for individual and multiple properties. When copying more than one property at a time, the Palette will paste only the properties for which an actual value is shown (as opposed to *****), and only the properties that are relevant in the object receiving the pasted properties.

You then learned about properties that control the behavior of data blocks. The General group of properties allows you to change the data block’s name, subclass the data block beneath another object or property class, and enter comments about the data block. The data block behavior properties include the Navigation group, Records group, Database group, and Advanced Database group. The data block appearance properties include the Scrollbar group, Font & Color group, Character Mode group, and International group. Behavior properties that are especially useful to developers are Query Array Size, which controls how many records will be fetched from the database at a time; Number of Records Buffered, which specifies how many records the Forms Runtime program will keep in the client computer’s memory when the form is run; and Query Allowed, which determines whether the user (or application code) can execute a query in a data block. The property named where clause enables you to enter filtering criteria to limit the types of records returned; order by clause allows you specify how the returned data should be sorted; Insert / Update / Delete Allowed lets you enable or disable the respective DML functions; Update Changed Columns Only specifies that when the user changes an existing record, the update command sent to the server only includes the fields that were changed; and DML Array Size controls the number of records that will be sent to the server in a batch. The properties relevant to the frame surrounding a data block include Frame Title Alignment, Number of Records Displayed, Distance Between Records, Bevel, and the Frame Title Font & Color group.

Next you learned how to create control blocks—blocks that do not directly correspond to a database. A control block contains either controls such as buttons, or a group of items with single values, such as calculated subtotals. Unlike data blocks, control blocks have a two-part creation process: create the control block, and then manually create the items that go into the block. When you delete data blocks and their components from the Object Navigator, the frame that contained the data block will remain on the canvas, as well as the frame’s title, which is an example of boilerplate text. The frame will no longer contain the data block or data block items, and the deletion cannot be undone. In contrast, when you delete a data block’s items and frame from the canvas in the Layout Editor, everything related to those items is deleted from the Layout Editor except the scroll bar: the frame and its boilerplate text are gone, as well as the items the frame contained. In the Object Navigator, the data block is still present but is an empty data structure. This action can be undone.

You then moved on to a new section discussing text items. A text item is any control on your form that displays text, numbers, dates, or long data, and allows the data to be edited by the user. This is in contrast to display items, which do not allow the user to change the data shown. You can modify a text item’s appearance by manipulating properties such as Justification, Format Mask, Distance Between Records, Visible, Visual Attribute Group, Prompt, Prompt Justification, and Prompt Visual Attribute Group. For controlling the data within a text item, Developer/2000 offers properties such as Case Restriction, Data Type, Maximum Length, Initial Value, Required, Lowest and Highest Value, and Calculation Mode. You can change the navigational behavior of a text item with properties like Automatic Skip, Keyboard Navigable, Previous and Next Navigation Item, and Show Vertical Scroll Bar. To enhance the relationship between a text item and a database, you can utilize such properties as Primary Key, Query Only, Query / Insert / Update Allowed, Query Length, Case Insensitive Query, and Update Only if NULL. The properties designed to modify the functionality of a text item include Enabled, Conceal Data, Popup Menu, Initial Value, Copy Value from Item, Calculation Mode, Formula, Summary Function, Summarized Block, Summarized Item, List of Values, and Validate from List.

After digesting the capabilities of those properties, you proceeded to learn about others enabling you to provide item-level assistance for your user by creating hints and tooltips. These invaluable text item properties include Hint, Display Hint Automatically, Tooltip, and Tooltip Visual Attribute Group. Further enhancing individual text items are Lists of Values (LOVs) and editors. An LOV is a window that displays a series of choices users can use to populate a text item. The LOV window is modal, so the user has to either make a selection from the list or dismiss it. When presented with an LOV, the user can employ a feature called autoreduction to select the list item they want with a minimum of keystrokes. The user can also search an LOV for strings that occur anywhere within the list’s values, not just at their start. An LOV can be customized using properties such as Automatic Display, Automatic Refresh, Automatic Select, Automatic Skip, Automatic Position, Automatic Column Width, X and Y Position, Width, and Height to tailor the look and feel of the LOV.

An editor is a dialog box that gives the user a larger space in which to type text. An editor provides Find and Replace functions, and you can customize its look and feel. You can also tell Developer/2000 to employ the operating system’s default editor instead of Developer’s internal editor by setting the Editor property to SYSTEM_EDITOR for the relevant text item.

All in all, this chapter comprises about 13 percent of material tested on OCP Exam 3.