Service Fields

Service fields are used in Screens and Dialogs. They have the appearance of transfer fields to the user, but they are not associated with a data field in the data base. Instead they are simply a place where the user can enter something, and your procedures can move that information to a variable in order to inspect it. Procedures can also move stuff to a Service Field, so they can act as a two-way message vehicle.

Click on the Service Field object in the def-specific palette, then click inside the frame to create a Service Field in the definition. When you click inside the frame you can make that click a drag, not only creating an instance of the field, but also determining its size all in one operation.

Put the cursor inside the Service Field and right-click in order to get its properties. You will see:

You must assign an Object Name so that your procedures can reference it. For more information see "named objects ."

Ignore "Tab Order." "Variable Name" can also be ignored, but it can be a handy documentation device. The idea is that you can tell yourself what variable name the procedures who interrogate this object will use. Then you will be reminded when you look at the properties and not have to dig into the procedures to rediscover this. It is not enforced, the burden is on you not to lie to yourself.

The remainder of the properties, the validations section and the special procedures section, are the same as for Transfer Fields, and are discussed in the topic named "Field Services ."