You are here: Development Standards > Upgrading OSAS > Converting to 6.xx Graphical > Creating Resource Files from OSAS Standard Code

# Creating Resource Files from OSAS Standard Code

The Advanced Software Development Utilities contains two programs that will generate resource files automatically from existing OSAS programs. The programs are called GENINPUT.PUB and SDBLDARC. You must run these utilities on a Windows-based system.

This special GENINPUT.PUB has been modified to record field sizes, types, lengths, and so on in a text file built to PRO/5 .ARC (ASCII Resource) file standards. (Refer to the BASIS manuals on ASCII Resource Files and RESCOMP.EXE for more information on the format of these files.)

SDBLDARC examines the 7500 section of code (character prompts) in the current workspace program and creates an .ARC file with this information. Finally, SDBLDARC merges the two .ARC files together into one and runs RESCOMP.EXE. RESCOMP.EXE is a BASIS utility (which ships with Resource Manager) that uses the combined .ARC file to create a .BRC file.

If your original character-based program has been developed in accordance with OSAS standards, the resulting .BRC file will require only minimal cleanup work to work with your programs.

Preparing and Installing the Utilities

Follow these steps before you install and use the utilities:

1. Install your Developer’s Kit. This includes both the Software Development Utilities and the BASIS utilities, so that you can run the BASIS ResBuilder utility. The installation process renames the existing GENINPUT.PUB and installs the Developer’s Version, which can be used to create graphical screens.
2. Move the BASIS utility RESCOMP.EXE and the file STDINCL.H (both of which should already exist in the progrm directory of your OSAS v6.5 install) into a Windows system path, such as \windows\command\. This is required because RESCOMP.EXE is called through an operating system command shell from within the application directories, so Windows must be able to find the programs.
3. Install your character application under OSAS 6.5.

Before Running the Utilities

The graphical screen creation utilities are designed to speed up the process of creating graphical resource files for use with OSAS programs. The utilities create a best-guess resource file, and you may need to clean up the resulting file a little before you use it with your programs.

However, you may find it more efficient to evaluate your programs and make certain changes before you run the utilities. Here are some suggestions for changes you can make before the creation to make the resulting cleanup process easier:

1. Check the 7500 section of the original program and remove spaces within PRINT statements, such as:
   `7500 PROMPTS:`
   `7510 PRINT @(2,2),”Customer ID From”`
   `7520 PRINT @(2,3),” Thru”`
   The spaces in these examples will cause the From and Thru prompts to be misaligned in the resulting resource file. Fix this problem with the following code:
   `7500 PROMPTS:`
   `7510 PRINT @(2,2),”Customer ID”,@(17),”From”`
   `7520 PRINT @(17,3),”Thru”`
2. Break up long prompts into separate prompts. In the above example, notice that the Customer ID and From prompts are split apart. Another example of this is as follows:
   `7500 PROMPTS:`
   `7510 PRINT @(2,2),”Pick Customer ID From”`
   Change this code to read as follows:
   `7500 PROMPTS:`
   `7510 PRINT @(2,2),”Pick”,@(7),”Customer ID”,@(19),”From”`
   This will allow your prompts to properly line up with each other.
3. Remove variables from positions in PRINT statements. For example:
   `7500 PROMPTS:`
   `7510 PRINT @(3,YPOS),”Pick”,@(7),”Customer ID”,@(19),”From”`
   `7510 PRINT @(19,YPOS+1),”From”`
   The screen cannot be created correctly from this code because, at the time the resource file is built, the value of YPOS is unknown. Temporarily replace this code with the actual position of the field to allow SDBLDARC to properly build the file for you. Then change your code back, if necessary, when done.
4. Repair programs that use this coding method for Yes/No fields:
   `1845 LET X0=12,X1=50,X3=5,X4=3,X$=YESNO$,X1$=”YESNO “`
   The resource creation program will build a list button for the Yes/No prompt in this example, which is not the proper GUI control. The proper coding method for Yes/No fields is to remove or clear the values in X1$ variable, as in the following example:
   `1845 LET X0=12,X1=50,X3=5,X4=3,X$=YESNO$,X1$=”“`
   When Yes/No fields are coded in this way, the resource creation program will build the proper check box, instead of the improper list button.

Using the Utilities

To build graphical screens, follow these steps:

1. From the OSAS menu, run the function for which you want to create a graphical screen.
2. At the first field on the screen. press Ctrl+A. The program name appears in the upper right corner of your screen, with the word ON after it.
3. Enter through each field on the screen, making sure that you have valid input in each field as necessary. As you enter through each field, the special GENINPUT.PUB program records field information. Do not use any commands (including the Up command), as fields may be recorded more than once or not at all. In addition, if you see any error messages that are generated in your program (such as ‘xxxxxx is not on file’ or ‘Thru value must be greater than from value’), you will also have duplicate field information recorded.
4. When you get to the last field on the screen, do not enter through the field. Instead, press Ctrl+A again to terminate the field recording and to run the SDBLDARC program.
5. When the Build BRC Now (Y/N)? prompt appears, enter Y to complete the graphical screen generation. When you do, the SDBLDARC program examines the 7500 section of the program currently loaded and builds the prompts into another .ARC file. The program then combines the field and prompt information in a single .ARC file and calls the RESCOMP.PUB program to build the resource file.
   The new resource files are created in the application programs directory. They are not created in the graphic files directory (such as /osas/gui) so that existing resource files are not accidentally overwritten. After the resource file creation is complete, you must move the file to the graphical files directory manually.

Cleaning up Resource Files

Once the resource file is created, use the BASIS ResBuilder utility to open and edit the file. The utility provides a graphical tool to manipulate the forms and controls in the resource file.

Use ResBuilder first to account for all controls that should be included on the form. Some fields may not have been included, because they appear only when certain conditions exist (such as application interfaces). These fields must be included in the resource file. They are usually hidden or shown by the code within the program where necessary (see Converting Your Programs below for more information on hiding and showing controls). Some fields must be added manually as well.

Follow these steps to check for changes necessary in the resource file:

1. Check for prompts and data entry that are displayed with a variable or based on an option switch. The following code is taken from ARPRH (Detail History Report)
   `7660 IF KIT THEN PRINT @(54,18),"Kit Detail",`
   In this example, you must have the option for keeping kit history turned on through Sales Order. This prompt will always be built into the resource file, but you may notice the input field missing. To alleviate this problem, make sure you have Bills of Material/Kitting installed and the option set. You should also create this screen using Sales Order rather than Accounts Receivable (which doesn’t have an option for kitting).
   Check also for missing F2 Inquiry tool buttons. Here is an example of code from an Accounts Receivable program:
   `1845 LET X0=I+3,X1=65,X3=0,X4=12,X$=TD1$(25+(I-1)*12,12),`
   `1845:GUI_ID=4090+(I*10),PROGID$="GLACGFM.PUB"`
   `1850 IF O2$(1,1)="1" THEN LET X3=13,X$=CVS(X$,2),X4=LEN(X$),`
   `1850:WINDID$="ARENTBW2",SELVAL$=CCID$+FILL(12)`
   The settings on line 1850 will be used only if you are interfaced to GL. If GL is not interfaced, no F2 button will be built next to the field of input.
   Check your programs closely for option-related code before you create the graphical screens. Finding and fixing option-related prompts, fields, and inquiry buttons in advance can save you time spent repairing the resource files later.
2. If the character screen is divided into sections, you must manually add group boxes to divide the graphical screen into sections. The creation program will not create the boxes for you.
3. Because selection fields (Sort By, Print By, and the like) are coded as numeric fields in the character-based code, the resource creation program will not change them to radio button groups. You must add the radio buttons and groups manually.
4. The utility creates a separate BRC file for each screen; however, the OSAS standard is to keep all screens for a program chain in the same BRC file for performance reasons. Therefore, after you create all screens for a function, use ResBuilder to copy and paste these screens into one resource file.
5. Horizontal Line Entry (HLE) screens are far more complex in layout. To create screens with a combination of regular entry and HLE, record the regular entry portion first, clean up your BRC as necessary, and then manually add the grid (or grids), scroll buttons, and command buttons using ResBuilder.

Other Resource Cleanup Issues

You must also make some additional changes to the resource files for internal standards reasons:

1. Add the proper name to each control in the resource file. The naming convention is to use an initial prefix that specifies the type of control (such as txt or cbo) and then a description of the control. See “Graphical Control Standards” for specific naming conventions. Failure to add the names will not affect your programs, but may cause confusion when working with the resource file at a later date.
2. The creation program builds the prompt for a Yes/No check box field independently from the check box control. You should add the text as a label in the check box control, resize the check box control if necessary, and then remove the static text control. Adding the prompt to the check box control will cause the system to display a dashed line around the prompt when the check box control gains focus.
3. Verify that the programs use the control numbering standards layed out above to avoid confusion and to enable possible future modifications.

Disabling Fields

In several graphical OSAS functions, many fields are disabled. This is generally done in maintenance, inquiry, and transactions screens to prevent the user from moving into other portions of the screen without entering required information.

In general, OSAS functions follow these rules for disabling fields:

1. In maintenance functions, enable the key field and disable all other fields until the key is entered. Then disable the key field and enable the remaining fields.
2. In inquiry functions, enable the field or fields that must be entered before data is displayed and the command bar becomes available. After the data is entered, disable the selection fields and enable the remaining fields.
3. In transaction functions, enable fields in groups to restrict movement as necessary. For example, you may enable only the key field (such as customer ID, vendor ID, or the like) while disabling all other fields. When the key field is entered, enable the remaining fields, keeping the key fields available because the user can arrow back to change them. In editing mode, disable fields that cannot be changed.
   Set the enabled/disabled properties of the controls in the resource file to their initial values to avoid the flicker that occurs when fields are displayed and then disabled.