Script_A Header information for use by the LFW system. These commands were automatically created by the LFW system. The LFW system uses the premise it is easier to edit than create, especially routine tasks. Commands that are required or normally modified are included.

Script_B Properties required by the view are placed after the /View_Client command. Other code for the "top" area of the view will follow the /Early_View_Area command. Register objects, procedures, and functions would be placed here, as well as USE or #INCLUDE statements. This is an area of the view accessible through delegation from all objects in the view.

Script_C Sets up the containers for this view. This view uses one large 3d box surrounding nested groups. The borders of the /Dialog_3d container can be changed, even set to none, using the VDF Border_Style command. The /Group command creates a visible container, with a title. The visible containers must have a visible border. The containers are automatically positioned by settings in the LFW.INI file. The position and/or size can be set using standard VDF set location, set size commands, or LFW equivalent ## commands. Using -1 for a setting tells the LFW system to compute a value, so one value can "hard" while the other "soft". Try to keep as "soft" as possible, like when using a word processor.

Script_D This is the first entry form of the view. The standard naming convention for database fields in the LFW system is fieldname#filenumber. In this example, the TYPE field in file number 207 (CODETYPE). The ##Fld commands also support the standard DataFlex style filename.fieldname (CODETYPE.TYPE). All of the DF field {} options have extended LFW ## equivalents. Most LFW ## commands also have DF {} style counterparts. The NoChangeLive and NoNull options in this field are examples of LFW commands in the normal DF entry options area. NoChangeLive means this is a key field and should not be changed for a live record. NoNull allows navigation through the object if null, but will not allow a null at save. There are, of course, command to allow change of key fields (OKChangeLive) and to allow null values (OKNull), even when they fall outside of a Range= range (only when using LFW validations). This field is Tabbed over 32 units, but lets the LFW system compute the vertical positioning. The LFW system maintains its own data dictionary, so it "knows" that this field heads an index . A prompt will be created automatically. As a matter of fact, even the selection list will be created if it does not exist.

Script_E This is a display only field of the CODETYPE.DESCRIPTION. It will have no label, be on the same line as the prior field, and positioned .5 columns after the prior field. If the prior field moves or changes size, the position of this field will automatically change. You will notice that the DESCRIPTION#207 field is presented on this screen in three times. This is called a dependent item and handled automatically by the LFW system. If an ASCII field is too long to fit its parent container, it is automatically trimmed using the margin parameters from the LFW.INI file for the type of parent container. All positioning and trimming automatically takes into account any prompt buttons.

Script_F Another instance of the DESCRIPTION#207 field. It is also display only, using the ##DFLD LFW command. The ##Stickytab ON command will set the tab position to that of the prior field. In this example, the position of the prior field is based on its prior field. The stickytab is also available for fields that follow. An entire screen, across multiple containers, can be anchored on a single field. There are three separate stickytabs available in the LFW system, and they can also be related by using the same technique. Windows screen design requires alignment for "proper" look. Stickytabs make this type of alignment possible when automatic positioning by the LFW system is not possible.

Script_G The actual entry form for the DESCRIPTION#207 field. It is in a different container than the other fields, but is aligned by use of the ##StickyTab LFW command. The ##Conditional_Entry LFW command is an example of power in a small package. This single line command creates all the support code for communication and testing between two entry objects. The line reads: Allow entry on this field if TYPE#207 is not blank. If TYPE#207 is blank, set this field blank. Test this relationship on every keystroke of TYPE#207. Shadowing is used to control access. An unlimited number of conditions can be put on the same field, and is not restricted to the value of one field. Simple OR and AND test logic is supported for multiple conditions. If the simple conditional entry does not have enough power, there is also a ##Conditional_Entry_Property LFW command which ties entry to the value of any integer property. The value of the property can be set in any procedure and/or function in the view. This field also has two validations. The LFW system has validation top and bottom command that reduces the programming required to create a validation. An unlimited number of validations can be added to a field, each having its own error message. The order the validations are executed is under programmer control, even the order of the LFW internal validation functions. The second validation makes use of the ##Get_Value LFW command. This command will get the value of any entry object, anywhere in the view. Notice the error messages for the field validations.

Script_H The COMMENT#207 field is a text field. The vertical size of the edit field is set to a size of four rows. The horizontal size and label location (and the label) are all computed by the LFW system. The ##Conditional_Entry LFW command tell the system to generate code to test that the DESCRIPTION#207 field is not blank. Conditional entry also cascades. If the TYPE#207 field is set blank, the DESCRIPTION#207 field is shadowed and set to blank. The COMMENT#207 field would then also be shadowed.

Script_I These commands close the containers. LFW commands are not case sensitive and can be indented. If there was code required for the bottom area of a container, it would be placed just before the end command. There is a LFW script command to end an entry object to allow access to this area if required. Custom programming is kept local to the area it supports.

Script_J The first button of the page. This ##BFLD LFW command will create a button with the label of "Do Info" that will send the do_info message when pressed. There are two LFW internal $$ replacements used in this button. $$RIGHT$$ is replaced with the width of the container, the right side. This button will be positioned 130 units to the left of the right side of the parent container. $$BUTTONSEND$$ is replaced with the send message name for the button, in this example "info_proc". Common routines can be programmed using the LFW $$ replacements, then pasted into the script. At the time of script processing, the replacements are made and the routines "fleshed out". The ##Pointer_Only LFW command is similar in effect to the VDF set focus_mode to pointer_only, except it also returns the cursor to the object that had the focus before the button press. Buttons can also have ##Conditional_Entry. Actually, almost any object in the LFW system can have ##Conditional_Entry.

Script_K Another button field placed standard LFW.INI button spacing after the prior button. The object name is Out_of_here. The LFW system makes up internal names for many objects such as grouping containers, buttons, and text fields. If access to these objects is required from custom programming, the objects can be named by the programmer. The object will have this name, and all internal LFW generated code will also use this name. The OnClick procedure sending the action message for the button is automatically created if it does not already exist.

Script_L The /Late_View_Area is where bottom code for the view resides. In this example, we are sending the KeyAction message to the button object named Out_of_here. The /View_Client_End LFW command ends the script. Comments and documentation can follow this command (but no ## commands) without affecting script processing.