View source for Screen Operations

[[Business Rules!]] advanced '''Screen Input/Output''' capabilities include many abilities:
* Print to and input from any position on the screen (full screen processing)
* Designation of one or more portions of the screen as its own mini-screen (windowing)
* Change the screen's display features through the use of screen attributes

==Full Screen Processing==

Full screen processing allows data entry [[controls]] on any position on the screen, specified by [[Row]] and [[Column]]. This contrasts with sequential screen processing, which allows prompted data display and entry with [[PRINT]], [[INPUT]], [[LINPUT]] and [[RINPUT]] statements, but only allows access to the bottom line of the screen. (Lines in regular screen processing then scroll up until they scroll off the top of the screen.) With full screen processing, any position on the screen may be addressed directly.

;Besides allowing access to any position on the screen, full screen processing provides several additional advantages:
# Screens can be attractively designed, making programs look extremely professional to the end-user.
# Less code is required. One screen that fully utilizes Windows control attributes and displays ten prompts and ten input fields can be programmed in as few as two statements.
# The operation of the input screen can be controlled. Control attributes may be used to specify starting cursor positions, automatic entry of data, field protection and more.

===Graphical Console===

A separate command console handles the operator commands without interfering with the graphical console. Print newpage goes to the command console if at the command prompt, and to both in a program.  [[Print]] anything else will only go to the [[command console]].

The [[GUI console]] can be opened to other than 80 columns by 24 rows:

An OPEN window statement may specify a parent window number:
George, Dallas, 42, 180

George, Peter, Tom

Version [[4.14]]+ will no longer display fonts as bitmaps. It will, by using only native graphical controls, support proportional fonts and variable window sizes. Caution- You may need to make programming changes to utilize this version.

Two fonts are supported simultaneously, one for background and captions and one font for input fields.

===General Coding Concepts===

;Always [[Print Newpage]] Before Full Screen Processing

Business Rules! does not automatically clear the screen when full screen processing is used. The program must do this with PRINT NEWPAGE. Neglecting to clear the screen when changing to or from full screen processing may cause errors in the operators new entry as old information may become interspersed with new.

====Multiple Field Processing====

The full screen processing statements allow you to input and output multiple fields with a single statement. This can be accomplished in two main ways: with repetitions of individual parameters directly within the full screen processing statement; or with the use of array parameters which reference a string variable, coded elsewhere in the program, that includes all the information required for the various specifications.

In the following example, six fields are processed by each of two full screen-processing statements. In each case, all information required to process the multiple fields is included in the actual statement. In line 140, the field definitions and variable names are specified for six prompts. In line 150, the current values are output and the changed values (as updated by the operator) are input; this line also includes field help information for two of the six fields.

 00120 DIM COMP$*25, STREET$*35, ADDR$*35, NAME$*20
 00130 PRINT NEWPAGE
 00140 PRINT FIELDS "6,11,c 20; 8,11,c 20; 10,11,c 20!:12,11,c 20; 14,11,c 20; 16,11,c 20" : PRID$, PRCOMP$,PRSTREET$, PRADDR$, PRNAME$, PRPHONE$
 00150 INPUT FIELDS "6,32,c 4,ra; 8,32,c 25,ra; 10,32,c 35,ra;12,32,c 35,ra; 14,32,c 20,ra; 16,32,c 12,ra",attr "R",help"XX2A<;Type in the street address.\nIf there is an apartment or suite number, \n type # and the number;2A<;Type in the full city name. \n Use the two-letter state code\n and the 9-digit zip code;": ID$, COMP$, STREET$, ADDR$, NAME$, PHONE$

One alternate way to code the above would be to place the field specifications and the field help window specifications each into their own array. The following code utilizes this technique but it operates exactly the same as the previous example. Line 220 prints the six prompts. Line 230 outputs the current values, accepts the updated values of the specified variables, and provides field help information on two of the six fields.

 00110 DIM PROMPT$(6)*20, FLDDEF$(6)*16, DATADEF$(6)*15,FIELDHELP$*200
 00120 DIM COMP$*25, STREET$*35, ADDR$*35, NAME$*20
 00130 ! **** Operator Prompts For Prompt$ Array
 00140 DATA ID number,Company Name,Street address,City/State/ Zip, Contact, Phone
 00150 ! **** Field Definitions For Prompts (FLDDEF$)
 00160 DATA "6,11,c 20","8,11,c 20","10,11,c 20","12,11,c 20","14,11,c 20","16,11,c 20"
 00170 ! **** Field Definitions For Data Entry (DATADEF$)
 00180 DATA "6,32,c 4,ra","8,32,c 25,ra","10,32,c 35,ra","12,32,c 35,ra","14,32,c 20,ra","16,32,c 12,ra"
 00190 READ MAT PROMPT$, MAT FLDDEF$, MAT DATADEF$
 00200 LET FIELDHELP$="XX2A<;Type in the street address.\nIf there is an apartment or suite number,\ntype # and the number;2A<; Type in the full city name.\nUse the two-letter state code \n and the 9-digit zip code;"
 00210 PRINT NEWPAGE
 00220 PRINT FIELDS MAT FLDDEF$: MAT PROMPT$
 00230 RINPUT FIELDS MAT DATADEF$,ATTR "R", HELP FIELDHELP$: ID$, COMP$, STREET$, ADDR$, NAME$, PHONE$

There are a few important items to be aware of when specifying multiple fields in full screen processing statements.
# When a string array is specified for field definitions (as with FLDDEF$ in line 220 above), extra elements in the string array will be ignored. Thus, if FLDDEF$ contained seven field definitions instead of six, the seventh would be ignored.
# The order of definitions in an array determines the order of processing. The first element of the array corresponds to the first item to be processed, the second element of the array corresponds to the second item to be processed, and so on. The order of items in the field definition does not affect your accessibility to the screen; you may define fields from the bottom of the screen to the top or from the top to the bottom or in any other way you prefer.
# It is important to remember that fields should be referenced in a consistent order throughout the full screen processing statement. The order that fields are referenced in the field definition array should be the same order that they are referenced with field help and variable names specifications.
# String and numeric fields may be intermixed in any order as long as the field definitions match the corresponding variable type. For instance, in the following example, the first field definition identifies a string field that starts at row 3, column 5 and is 20 characters long. This field definition corresponds to the first variable (NAME$) in the I/O list. Likewise, the second field definition identifies a three-digit number which corresponds to the numeric AGE variable.

 1000 INPUT FIELDS "3,5,C 20; 7,5,N 3" : NAME$, AGE

==Windowing==

One of Business Rules most powerful screen I/O capabilities is the ability to separate the screen into several mini screens, or I/O windows. These windows can do all the same things (including scroll) that the regular full screen can do. In addition, an I/O window may have a border and a caption in the top line of the border.

===Open Display (Screen)===

 00410 OPEN #0: "Srow=nn, Scol=nn, Caption=APPLICATION NAME", DISPLAY, OUTPUT
                -or-
 00420 OPEN #0:"Srow=nn, Scol=nn, Caption=APPLICATION NAME, Buttonrows=nn",DISPLAY, OUTPUT

00420 Open #0: opens the main window,  A number other than Zero opens a child window if "PARENT=XX" is included in the open string and XX refers to an existing open window number.

Opens a Windows window.  Optionally sets the number of button rows (0-3). (Button rows are additional rows at the bottom of the screen that Business Rules can use for optional button placement.)

Display file OPEN file reference strings can contain COPIES=nn.  The nn value will replace the new [COPIES] argument in SPOOLCMD.

===Windows vs Field Help Windows===

Although they share many similarities, Business Rules I/O windows and field help windows are specified in very different ways and they are used for very different purposes.

The primary difference is that Business Rules treats an I/O window as its own input/output file. Information may be sent to and received from it with statements such as PRINT, INPUT, LINPUT, and RINPUT.

In addition, information may be sent to and received from a window (as if it were the regular screen) by the full screen processing statements.

In contrast, input from and output to field help windows are not allowed. Field help windows and the text, which appears within them, are specified by the full screen processing statements; they are designed to help the end-user determine what to do for a particular field.

The following chart should help to clarify other similarities and differences between I/O windows and field help windows.

[[Image:NEWC0050.jpg]]

===Border===
Requires [[4.16]]+

WINDOW BORDERS

BORDER= any valid border spec produces a single line border.

BORDER= NONE produces no border, same as not specifying a BORDER parameter at all.

===Borders (Legacy)===
Only supported in Business Rules! versions prior to 4

One of the greatest similarities between I/O windows and field help windows is in the types of borders that are available for each. For I/O windows, borders are specified with the [[OPEN window]] and [[PRINT BORDER]] statements. For field help windows, they are specified with the [[FieldHelp]] specification.

Each of these three specifications uses syntax, which is nearly identical, where the border type is concerned. Each has a "BORDER" keyword (in the case of OPEN window, its "BORDER=") followed by one of six options for specifying the border: "B" (blank), "D" (double-line), "H" (sHadow), "S" (single-line), "corners", and "8 chars".

 The first four border options are predesigned. The following illustrations show examples of each. (Keep in mind that the attributes specified with a border provide hundreds of opportunities for variation.)

[[Image:HELP0134.jpg]]

The last two border options allow you to custom-design your own borders. With the "corners" parameter, you can specify just the top left and bottom right characters (and let Business Rules fill in the rest). Or with the "8 chars" parameter you can specify eight characters that identify the corner and middle characters for every side of the border. The following illustration shows the sequence in which the eight characters must be specified:

1|2|3

8||4

7|6|5

The following example shows the use of the "8 chars" parameter with graphic drawing characters which may be toggled on for the 0-9 and period (.) keys by pressing Ctrl-\. This example creates the same border that is created by the S border type. It also includes the "r" attribute to reverse the border.

[[Image:HELP0135.jpg]]

The next sample code shows some of the options that are available with borders for windows. A good way to see both windows and field help windows in action would be to type this code in and use the RUN STEP command to execute it.

 00005 PRINT NEWPAGE
 00007 DIM FIELDHELP$*50, NULL$*50
 00009 EXECUTE "config fieldhelp border=H"
 00010 OPEN #1:"srow=4,scol=10,erow=8,ecol=37,border=S,caption =>S (Single-line border)",DISPLAY,OUTIN
 00020 OPEN #2: "srow=4,scol=45,erow=8,ecol=72,border=d",DISPLAY,OUTIN
 00030 PRINT #2, FIELDS "3,4,cc 22": "D (Double-line border)"
 00040 input fields "12,15,c 50,r",help "1B; This is a field help window \n using an H (sHaded) border. \n \n Type in any CONFIG FIELDHELP \n specification such as the following: \n CONFIG FIELDHELP BORDER=BR;": FIELDHELP$
 00045 PRINT FIELDS "12,15,C 50,N": NULL$
 00050 EXECUTE FIELDHELP$
 00090 INPUT FIELDS "18,35,c 18",help "1A; This window uses the border you specified. \n If you typed in the suggested border, \n it is B (blank) using the R (reverse) attribute.\n \n Now watch the upper left window while pressing<CR> \n to see the effects of PRINT BORDER.;": CR$
 00100 PRINT #1, BORDER "*-*|*-*|": "custom-designed border"
 00105 CLOSE #1,DROP:
 00106 CLOSE #2,DROP:

In the above example, line 9 uses an [[EXECUTE]] statement to set the border type for all field help windows. Line 10 opens an I/O window with a single-line border and a caption in the top border that is right justified and says "S (Single-line border)".

Line 20 opens an I/O window with a double-line border. Line 30 then centers the string "D (Double-line border)" within the window. NOTE that the row and column specified in this statement assume that the top left corner of the window is row 1, column 1.

Line 40 specifies a field that accepts input on line 12 of the regular screen. It includes a field help window with text that describes its border as a shaded border (this border type for field help windows was specified back in line 9). This window also tells the user to type in a CONFIG FIELDHELP specification that identifies a new border type for field help windows.

Line 45 prints a null string over the area where the reversed input field for line 40 appeared, thus cleaning up the screen.

Line 50 executes the string typed in for line 40 to change the border type for all field help windows.

Line 90 specifies an input field that accepts input on line 18 of the regular screen. It includes a field help window that utilizes the new field help border type executed in line 50. It then instructs the user to watch the upper left window to see the effects of a PRINT BORDER statement.

Line 100 uses PRINT BORDER to change the border in window #1. The specified border uses the "8 chars" parameter, which is available in all the Business Rules instructions that specify border types (OPEN window, PRINT BORDER, and FIELDHELP).

Lines 105 and 106 close and drop the contents of the two open windows. Although the terminology may seem a little confusing at first, the act of closing a window causes the window's border to disappear and the information that was hidden by the appearance of the window to be restored. Thus, if lines 105 and 106 simply closed (without dropping) windows #1 and #2, the borders would disappear and a blank screen would be restored.

However, the act of closing and dropping a window file leaves the current contents of the window and its border intact at the same time that it drops the information that was hidden by the appearance of the window.

===Using I/O Windows to Save the Screen (Prior to 4.0)===

Beginning with 4.17 the [[TABS]] feature is used to display multiple windows and switch between them.  See TABS later in this chapter.  Saving a portion of the screen is not necessary after 4.0 because the graphic window that is opened on top of an existing window does not destroy the information on the layer below.  The underlying information automatically becomes visible when the top window is closed.  In versions prior to 4.0 there were not separate layers, consequently the replaced information would need to be saved in a separate screen file and restored (closed) when the overlaying information was no longer needed.

Saving all or part of the screen is very easy with I/O windows. All it requires is opening a borderless window using row and column parameters that encompass all the information to be saved. The following example saves an entire screen without making any changes to the appearance of the screen:

 00670 OPEN #1:"SROW=1,SCOL=1,EROW=24,ECOL=80:,DISPLAY,OUTIN

It is useful to note that an OPEN window statement's row and column parameters identify the inside portion of a window. If a border is specified for a window, it is always placed one position outside the specified row and column.

Once an entire screen has been saved with a window, the existing screen may be altered any number of times without affecting what was saved from behind the window. Restoring the saved screen (including all attributes) is accomplished with a CLOSE statement as follows:

 00750 CLOSE #1:

The capability of saving a screen becomes very useful when you wish to switch between overlapping windows. The following example demonstrates such a use:

 00010 print NEWPAGE
 00020 open #1: "srow=5,scol=5,erow=15,ecol=50,border=dn",display,outin
 00030 print #1,fields "1,2,c 30": "Business Rules window 1"
 00040 print #1,fields "10,2,c 30": "F1 to go to window 2"
 00050 input #1,fields "4,4,c 10,u": X$
 00060 if CMDKEY<>1 then goto 180
 00070 open #101: "srow=4,scol=4,erow=16,ecol=51",display,outin
 00080 if FILE(2)<>-1 then goto 130
 00090 open #2: "srow=8,scol=20,erow=18,ecol=61,border=dn",display,outin 
 00100 print #2: NEWPAGE
 00110 print #2,fields "1,2,c 30": "Business Rules window 2"
 00111 print #2,fields "9,2,c 30": "F1 to go to window 1"
 00120 goto 140
 00130 close #102:
 00140 input #2,fields "4,4,c 10,u": X$
 00150 if CMDKEY<>1 then goto 180
 00160 open #102:"srow=7,scol=19,erow=19,ecol=62",display,outin
 00170 close #101: : goto 50
 00180 stop

Essentially, the above program allows the user to switch between two windows by pressing the F1 key (lines 50 and 140). If the user presses F1 from window #1, the program saves window #1 by opening a borderless window (#101) that encompasses the data area of the window. It then opens window #2 (if window #2 already exists, window #102 is restored). If the user then presses F1 to go back to window #1, the contents of window #2 are saved in window #102. Window #101 is then restored (over the top of window #2) with the CLOSE statement. The same sequence of saving and restoring windows can continue indefinitely.

The above sample works well when running on [[CONFIG GUI OFF]] mode.  This was the only available mode in version prior to 4.0.  With the introduction of []CONFIG GUI ON]], "Using I/O Windows to Save the Screen", is no longer appropriate.  

In [[CONFIG GUI OFF]] mode, opening a new window will preserve any information displayed at the time the window was created.  Essentially, the information "behind the window", will "bleed through" the newly opened window.   You may change any information on the screen that has been protected by this window, and when you close the window, the original text will be restored.

In the above sample, there is the illusion of multiple layers, but in reality, each window is only preserving a "screen shot" of the information, and not maintaining each of the layers.   In other words, your 80 x 24 visible screen looks correct, but no other information is displayed.  Information may be printed to any of the virtual layers, and it will be visible to the user, and when you close the window, the original text will be displayed as originally captured.

As an example, you can update a window that covers part of the screen, and use Print #0, to update the "Visible Area" in front of the window.   Later when you close the window, the original information will be restored.

Following the above example application, in GUI OFF mode:

Line 10 erases the screen
Lines 20-50 Open Window #1, (5,5 to 15,50) and display some information.

When the user presses "F1":
Line 70 "Protects Window #1, (4,4 to 16,51), by opening window #101.  Notice this new window is large enough to cover the line draw.
* Note: Window #1 is still open, and could be used to display information, but regardless of how the screen is updated, the entire original information will be restored when window #101 is closed.

Line 90-120 Open Window #2, (8,20 to 18,61) and display some more information
* Note: Window #2 covers up some of both windows #1 & #101.  Again, Window #2 protects the contents of these two windows.   And regardless of how the screen is updated (Handles #1,#101 or #2), the original information protected by window #2 will be restored when Window #2 is closed.

Again the users presses "F1":
Line 160 "Protects Window #2, (7,19 to 19,62), by opening window #102, Notice this new window is large enough to cover the line draw.
* Note: Windows #1,#101 and #2 are still open, and could be used to display information, but regardless of how the screen is updated, the entire original information will be restored when window #102 is closed.

The next line performs some "Fancy Magic".
Line 170 closes Window #101,  (4,4 to 16,51)   This causes the original text protected by Window #101 to be "restored".  The effect of closing this window is that the original text created by Window #1, and then protected by Window #101, is now restored.

As you continue pressing F1, windows #101 & #102 take turns protecting and the restoring the two windows.  The effect of this programing is the user sees what appears to be two complete layers.   In other words, there is the illusion that the contents of both windows are actually still on the screen, and that pressing "F1" is switching layers.



In [[CONFIG GUI ON]] mode, opening a new window actually create a new layer or container without affecting the information behind it.  The new window is now transparent, so the effect is very similar to a [[Print Newpage]] command.   This new window may or may not have a border.  In this mode, you no longer have a single 80 x 24 layer, rather each window has it's own private space.   Information must be printed to the correct layer.   

As an example, you can open a window that covers part of the screen, and use Print #0, to update the "Hidden Area" behind the window.   Later when you close the window, the updated information will be displayed.

Examining the same code again, but using the GUI ON mode:

Line 10 erases the screen
Lines 20-50 Open Window #1, (5,5 to 15,50) and display some information.

When the user presses "F1":
Line 70 "Completely covers Window #1, (4,4 to 16,51), by opening window #101.  
* Note: Window #1 is still open, and intact, but is no longer visible because window #101 is actually a new layer and contains no information   Windows are not transparent in GUI ON mode.  Window #1, remains unaffected as long as nothing is printed directly to Window #1.   You could if desired, update Window #1 directly, but the changes would not be immediately apparent.


Line 90-120 Open Window #2, (8,20 to 18,61) and display some more information
* Note: Window #2 creates a new layer that covers up some of both windows #1 & #101.  Because Window #101 is hiding Window #1, Window #2, appears to "Pop-Up", with Window #1 "Disappearing".


Again the users presses "F1":
Line 160 "Completely covers Window #2, (7,19 to 19,62), by opening window #102. Now the screen appears to be blank.
* Note: At this point, Window #1, is covered by Window #101, and Window #102 partially covers Window #1 & #101.   Window #102 is the "Top Layer".

Line 170 closes Window #101,  (4,4 to 16,51).  This causes a rather strange effect as compared to the GUI OFF version.  Window #1, is now partially visible because it is not covered by Window #101.   However, Windows #2 & #102 are still partially covering Window #1.   The effect is that Window #1 appears "Broken".


As you continue pressing F1, windows #101 & #102 take turns partially hiding the two windows.  In GUI ON mode, this sample application looks terrible!

Make the following few changes to the sample program.

 00070 ! OPEN #101: "srow=4,scol=4,erow=16,ecol=51",DISPLAY,OUTIN
 00130 ! CLOSE #102:
 00160 ! OPEN #102: "srow=7,scol=19,erow=19,ecol=62",DISPLAY,OUTIN
 00170 ! CLOSE #101: !:
       GOTO 50

These small changes create a new behavior that is more appealing.  Now, pressing "F1" will simply move focus between the two windows.   Notice that Window #2, always covers Window #1, but the user can still enter data as the focus changes.

A few more changes create the following example:

 00010 PRINT NEWPAGE
 00020 OPEN #1: "srow=5,scol=5,erow=15,ecol=50,Tab=Window 1",DISPLAY,OUTIN 
 00030 PRINT #1,FIELDS "1,2,c 30": "Business Rules window 1"
 00040 PRINT #1,FIELDS "10,2,c 30": "F1 to go to window 2"
 00050 INPUT #1,FIELDS "4,4,c 10,u": X$
 00060 IF FKEY=93 OR FKEY=99 THEN GOTO 180
 00080 IF FILE(2)<>-1 THEN GOTO 140
 00090 OPEN #2: "srow=5,scol=5,erow=15,ecol=50,TAB=Window 2",DISPLAY,OUTIN 
 00100 PRINT #2: NEWPAGE
 00110 PRINT #2,FIELDS "1,2,c 30": "Business Rules window 2"
 00111 PRINT #2,FIELDS "9,2,c 30": "F1 to go to window 1"
 00120 GOTO 140
 00140 INPUT #2,FIELDS "4,4,c 10,u": X$
 00150 IF FKEY=93 OR FKEY=99 THEN GOTO 180
 00170 GOTO 50
 00180 STOP 

Run the program, and press "F1" as instructed.  Notice that the tabs in fact are separate layers that preserve the text you type.  As long as you are in GUI Mode, feel free to use the mouse to navigate the tabs.
This modified version will only exit when you press Escape, Alt-F4 or click on the "X" to close the window.

==Syntax of Statements==

;Each of the full screen processing statements has basically the same syntactical form, which can be divided into the following six portions:
:1.) Statement name and I/O location.
:2.) Field definition.
:3.) Attribute for current field (not applicable for PRINT FIELDS).
:4.) Field help specifications (not applicable for PRINT FIELDS).
:5.) I/O list.
:6.) Error condition list.

Each of the above portions are identified in the following syntax diagram for full screen processing statements. This diagram will be used for reference in describing the syntax of four of the five of the full screen processing statements. (See the Statements chapter for a separate description of the PRINT FIELDS statement.) Since the following syntax diagram is rather complex, each portion will be described separately in the parameter descriptions that follow.

[[Image:HELP0131.jpg]]

;Defaults:
:1.) Display to and input from the screen.
:2.) Do not alter attribute when field is current.
:3.) Do not display field help text.
:4.) Interrupt the program if an error occurs and "ON error" is not active.

===Statement Name I/O Location===

The "Statement name, I/O location" portion of the syntax for full screen processing statements identifies the statement being used and the file number of the window which is to be used for input or output.

;Parameters:
The primary keyword ("INPUT", or "RINPUT") of the statement being used must be specified first.

"Wind-num" references a window file that has already been opened by an OPEN window statement. When this parameter is used, Business Rules input from and output to the window as if it were a separate screen: the first row and column of the window will be considered row 1 and column 1. When "wind-num" is not specified, file #0 (the full screen) is assumed.

The secondary keyword ("FIELDS" or "SELECT") of the statement being used must be specified next.

===Field Definitions===

;Purpose:
The "Field definition" portion of the full screen processing syntax identifies the following for each field: row number; column number; format type; length of the data to be input; and the monochrome, color and control attributes which are to be used for the field.

;Comments and Examples:
The following statement identifies a field that starts at row 6, column 3. The field is numeric and has a total length of 7 characters, one of which is a decimal point and two of which are decimal digits. When the statement is executed on a monochrome monitor, the field will appear as reversed and highlighted. When the statement is executed on a color screen, the background of the field will be red. The name of the variable to which input will be assigned is AMOUNT.

 00750 INPUT #7, FIELDS {\b "6,3,N 7.2,HRE/:R"}: AMOUNT

;Insertable syntax ("field-spec" parameter):
[[Image:HELP0132.jpg]]

;Defaults:
:1.) Fraction length = 0.
:2.) Maximum DIM length.
:3.) Use current attributes.

;Parameters:
The above syntax may be inserted where the "field- spec" parameter appears in the main diagram for full screen processing statements. If the "string-expr" or "MAT string-array" parameters are used to specify the field definition, each must include the same elements that are identified in the "field-spec" parameter.

The "row" parameter is a required integer value that indicates the row number on the screen or in the window where the data is to be entered.

The "column" parameter is a required integer value that indicates the starting column number on the screen where data is to be entered.

The next set of parameters specifies the format type of the data to be entered. There are three possible routes.

In the top route, "num form-spec" represents a numeric format specification. G, GL, GU, GZ, L, N, and NZ are all valid in this position; the specification must be followed by a space. The "field-length" parameter, which is an integer value that identifies the length (including decimal point and decimal positions) of the field, comes next. If the field contains decimal positions, "fraction" should identify how many there are; this parameter must be separated from the field length by a period (no spaces).

In the middle route, "string form-spec" represents a string format specification. C, CC, CR, CL, CU, G, GL, GU, GZ, V, VL and VU are all valid in this position. If "field length" is used, it must be separated from the format spec by a space.

In the bottom route, the "PIC" or "FMT" specification allows you to specify a picture of the field to be input. See the File I/O chapter for a list of the characters that may be used in the "(pic-spec)" portion of this parameter.

See the File I/O chapter and APPENDIX F Format Specification for additional information about all the format specifications listed in this section.

The "attributes" parameter represents an insertable syntax that identifies the monochrome, color and control attributes that are to be used for the field. See the Definitions chapter for the insertable syntax and for additional information about this parameter.

Additionally fonts can be controlled at the field level by assigning them to attribute substitution letters as in:

:CONFIG ATTRIBUTE [J]RH,font=ariel,slant,max \line This specifies reverse highlight ariel italics maximum size.

===Attribute for Current Field===

;Purpose:
The "Attribute for current field" portion of the full screen processing syntax identifies the attribute that should be used for the field that the cursor is on.

;Parameters:
The "ATTR" keyword identifies that a separate set of attributes should be used for the current input field. It must be followed by either the "attributes" parameter or the "string-expr" parameter. "Attributes" represents an insertable syntax that identifies the monochrome, color and control attributes that are to be used for the field. See the Definitions chapter for the insertable syntax and additional information.

If used, the value of "string-expr" must include the same elements as are required in the "attributes" parameter.

;Hot text

Hot text may be displayed as either text or buttons. To make it display as a button, the trailing attribute specification should be a B followed by the fkey value to be returned when the button is clicked. e.g.  "20,5,CC 12,,B1244"  displayed as a button with fkey value 1244. Beginning with 4.16 the default behavior for a Hot Text field is a button.  The Button may be suppressed by using an "H" instead of the "B" or no letter.

Any FIELDS text may now generate a keyboard scancode when double clicked, similar to the way BUTTONS and the Combo Box graphic do. Even linedraw characters can be "hot".

When a picture is specified as an input field, all non-navigation keys are ignored.

;Additionally fonts can be controlled at the field level by assigning them to attribute substitution letters as in:

;The Shaded Sunken Appearance:

Normal Windows behavior is to grey out any data entry fields that are inactive. Consequently, this is how labels appear when they are sunken. This defeats the ability to use a sunken approach to hilight screen headings. For example if you specify SCREEN U 0173 and then specify U as a leading attribute in a PRINT FIELDS specification, the field will be displayed sunken but grey.

You can now override the normal Windows behavior with regard to greying out sunken labels by specifying S as a leading attribute. The S (sunken- formerly shaded) field attribute calls for a white sunken field irrespective of whether the field is open for input.

;Fields Color Attributes

In an input or print fields statement the attributes after the slash can only contain valid color attributes such as HRGB or #RRBBGG.  In the past the "N" attribute was accepted in this location.  Beginning with 4.17i any non-color attribute in the color section will generate an error.

;Additional Date() Formats are supported:

[NEWCELL(icells2l.spc)]

Also, a new FIELDS format is supported

 row,col,DATE(dd/mm/yy)

The values are displayed as dates but are stored internally as day of century. The mask may be any valid DATE() mask.

===Field Help Specifications===

{{:Field Help}}

===I/O List===

;Purpose:
The "I/O list" portion of the syntax for full screen processing statements identifies the information that is to be input or output by the statement.

;Comments and Examples:
With [[INPUT FIELDS]] and [[INPUT SELECT]], the I/O list identifies the variables to which the input is to be assigned. With [[RINPUT FIELDS]] and [[RINPUT SELECT]], the current values of the I/O list are output, the output values are updated by the operator, and the updated values are re-input to the specified variables.

;Parameters:
A colon (:) must separate the I/O list from any previous parameters in the full screen processing statement. At least one "var-name" or "MAT array-name" must be specified. These two parameters represent the list of variables to be assigned values from the entered data. multiple variables must be separated by commas

===Error-Cond List===

;Purpose:
The "Error-cond list" portion of the full screen processing syntax identifies the types of errors that should be trapped and where execution should be transferred to when such errors are trapped.

;Parameters:
The "error-cond" portion of the parameter identifies the error to be trapped, and the "line-ref" portion identifies the line to which execution should be transferred when such an error is trapped.

;Technical Considerations:
1.) Relevant error Conditions are: CONV, Error, Exit, Help, IOERR, and SOFLOW.

===Console Characteristics===

The name of the directory with examples for this section is: EXAMPLES\CONSOLE

A separate command console handles the operator commands without interfering with the graphical console. PRINT NEWPAGE outputs to the command console from the command prompt, and to both consoles in a program.  Regular PRINT statements and PRINT USING statements output only to the command console.  PRINT FIELDS and PRINT BORDER output only to the graphical console.

The name of this example is: CONSOLES.BR

 00100 PRINT NEWPAGE ! output to both consoles
 00200 PRINT "ABC" ! output to command console
 00300 PRINT using "form C 4,C 2,N 2" : "WXYZ","  ",24! output to command console
 00400 PRINT FIELDS "15,4,C 15": "million dollars"! output to graphical console
 00500 PRINT #0, BORDER "Billion dollars":! output to graphical console

;Output:
[[Image:NEWC0009.jpg]]

The consoles can be opened to other than 80 columns by 25 rows:

 OPEN #0: "Srow=5,Scol=5,Rows=30,Cols=100", display, outin  ! specifies position on screen  and size in chars

An OPEN window statement may specify a parent window number. In the following example, window #1 is opened as a child of window #0. Srow= and Scol= reference window #0.

The name of this example is: CHILDWIN.BR

 00100 OPEN #1: "SROW=2,SCOL=2,EROW=5,ECOL=20,border=S,caption=MyWindow,Parent=0",display, outin

;Output:
[[Image:NEWC0010.jpg]]

File numbers 300-999 are now supported in addition to those below 200.

When a user defined Windows menu is displayed, the Preferences menu is suppressed. When the user-defined menu is cleared, Preferences is restored.

===Datahilite===

The default under Windows is to reverse each field as it is entered, and to position the cursor at the end of the data.This type of processing can be turned off, by specifying DATAHILITE OFF in the BRconfig.SYS file.

;3D Fields applies to pre 4.0 versions:

The 3D FIELDS parameter UNDR ON ignores all other attributes for underlined fields.  Traditionally, BR has used either the N (normal) attribute or R (reverse) attribute and ORed the other attributes specified (H, B, and U).  Now it works the same way, unless UNDR ON is specified and U is present, in which case it uses the U value exclusively.  This provides greater control over the color scheme with 3D FIELDS active.  You can use H for other purposes without affecting UH processing.

{\b CONFIG DATAHILITE WIN ON} indicates that the user's Windows specifications for selected text should apply to highlited text.

{\b CONFIG DATAHILITE WIN OFF} can be used to turn this feature off.

;Two new parameters were added to the {\b DATAHILITE} configuration statement:

XX Uses color attribute XX (as specified in a SCREEN statement) for the "selected" text.<br>
[X] Use the color specification associated with [X] in the ATTRIBUTE configuration statement.

The 3D FIELDS parameter UNDR ON ignores all other attributes for underlined fields.  Traditionally, BR has used either the N (normal) attribute or R (reverse) attribute and ORed the other attributes specified (H, B, and U).  Now it works the same way, unless UNDR ON is specified and U is present, in which case it uses the U value exclusively.  This provides greater control over the color scheme with 3D FIELDS active.  You can use H for other purposes without affecting UH processing.

FIELDS3D has been changed to 3D FIELDS.

When 3D fields are enabled, the screen requires more vertical space than it otherwise would.  Therefore, the BR window takes on a rectangular appearance, and doesn't look as good in full screen mode as it does as a window.

To activate this feature, specify 3D FIELDS ON in your BRconfig.SYS file and also specify SCREEN U 0170 only.  (Or specify SCREEN U 0170,N 38 to add some flair.)

You can also use the CONFIG command to activate this feature, but if so, you must OPEN #0: "SROW=1,SCOL=1", DISPLAY, OUTIN after executing the CONFIG command.

Specifying 3D FIELDS in BRconfig.SYS is not sufficient to activate it.  You must also either precede a standard field attribute with 01 (e.g. U 0170) or specify S as a leading field attribute in your FIELDS specification.

e.g. INPUT FIELDS "10,10,C 10,S": X$   The preferred way for legacy code to activate 3D FIELDS is to use the SCREEN statement.

Ctrl-Z will act as undo when DATAHILITE is on.

===Window on a field===

The ability to enter and process more text than a window field can display at one time is included.  This is a very powerful feature that lays the groundwork for support of proportional fonts.  You will, for example, be able to enter and maintain fifty characters of data in a twenty character field on any platform.

;The syntax for enabling this capability is:

 00100 INPUT FIELDS "row,col,20/C 50,N/W:W": name$

Which enables up to 50 characters to be entered into a 20 character window field.

;This syntax was changed in the July release of BR 4.17. It used to be:

 00100 INPUT FIELDS "row,col,C 20/50,N/W:W"

where 20 was the width of the "window" and 50 was the allowed width of the data entry field.  4.17 changed this so that it would be compatable with more format statements (and easier to understand).

This new syntax also works for

 00100 INPUT FIELDS "row,col,20/PIC(##D##D##),N/W:W"

and for

 00100 INPUT FIELDS "row,col,date(M3 d, cy),N/W:W"

;Window on a field processing

The syntax for window on a field has been changed to accommodate more options.  The displayed length of the field is the first parameter and precedes the field size.

 01200 RINPUT FIELDS "10,20,40/C 100,N/W:W":TEXT$

Displays and allows input to a 100 character variable TEXT$ in a field that only uses 40 characters of screen space.

To accommodate extended field capacities with 'display under mask' field types, BR now uses the following syntax:

row,col,displayed-length/field-spec<br>
e.g.   5,10,7/N 10.2<br>
          - 10 digits with decimal point displayed in 7 char field<br>
 or    7,10,11/PIC(#,###.##)<br>
          - 7 digits with punctuation displayed in 11 char field

The main use for this feature is to shorten the displayed length when displaying proportional fonts as in  9,10,20/C 25.

OPTION 45 allows the old method of extended field specification in addition to the new method. If the older format is encountered without Option 45, then error 861 is reported.

;Text Box

A text box with wrapping text can be displayed in BR if the field is opened in a window.  An input fields statement that exceeds the width of the window will wrap within the window and allow data entry in wrapping format.

 00100 OPEN #10:"SROW=10,SCOL=10,ROWS=5,COLS=20",DISPLAY,OUTIN
 00200 RINPUT #10,FIELDS "1,1,100/C 2000,N/W:W":TEXT$

Will wrap an input fields data entry field within a window that is 5 rows by 20 columns.  This window will wrap and scroll to allow entry of a 2000 character string.

==Graphical Controls==

'''Graphical Controls''' are also known as [[Widgets]].

RADIO Buttons and CHECK Boxes will work with PRINT, INPUT, and RINPUT operations.  A COMBO box may be processed with separate PRINT and INPUT statements. A COMBO box may also be processed with RINPUT after it has been populated with a PRINT statement. However, GRID and LIST require separate PRINT and INPUT statements and do not allow RINPUT.

===Combo Boxes===

{{:Combo Boxes}}

===Check Boxes===

{{:Check Boxes}}

===Radio Buttons===
{{:Radio Buttons}}

===MsgBox System Function===
See [[Internal Functions]]

===Combo Box Character===

The combo box character is supported like it is by the old console (Q as a leading attribute plus specification of an fkey value).

===Fonts And No Graphical Control Overlap===

Labels (strings) displayed are analyzed for spacing.. If more than one blank is found or line draw or underline characters are encountered, a new control delineated. When such individual controls (label segments) are delineated the last non-whitespace character of each subfield is check for a colon. If it is a colon the text is right justified within the subfield.

IF A CHR$(5) CHARACTER IS ENCOUNTERED IT IS REPLACED BY A BLANK AND A CONTROL BOUNDARY IS DELINEATED.  Delineating a new control implies continuing output at the position where it would be if the window were using fixed fonts. This can be useful when setting up a multi-column INPUT SELECT line. This is because INPUT SELECT does not align columns with proportional fonts the way PRINT FIELDS does. Ultimately it will be preferable to recode your lookups or zooms to use LISTview.

One of the disappointments in moving to a GUI presentation is that text selection via DATAHILITE overrides the ATTR value. ATTR still applies to the 'current' field (where the cursor is) once the data is deselected. But the color of selected text is necessarily determined by the operating environment. If you want to override the color of the current field immediately upon entry, then you will have to turn DATAHILITE off so the text will not be selected upon entry.

===New Fonts and No Graphical Control Overlap===

All window displays consist of true Windows/MAC graphical controls and *proportional fonts* are supported along with non-proportional fonts. Proportional fonts are not rendered fixed size. Positioning of controls and sizing of controls on the window are managed by simulating fixed character positions.

Hot text may be displayed as either text or buttons. The default is to display it as a button.  To override this default the trailing attribute specification should be an H followed by the fkey value to be returned when the button is clicked.

e.g.
   "20,5,CC 12,,B1244"  displayed as a button with fkey value 1244
   "20,5,CC 12,,H1244"  displayed NOT as a button but returns fkey value 1244

The cursor changes to a hand pointer only for hot text and pictures. It does not do so for buttons because it is self evident that they are hot.

Labels (captions) displayed are analyzed for spacing.. If more than one blank is found or line draw or underline characters are encountered, a new control is delineated. When such individual controls (label segments) are delineated the last non-whitespace character of each subfield is check for a colon. If it is a colon, the text is right justified within the SUBfield. In other words, the colon right aligns the data WHERE IT WOULD BE IF YOU WERE USING FIXED WIDTH FONTS.

IF A CHR$(5) CHARACTER IS ENCOUNTERED IT IS REPLACED BY A BLANK AND A CONTROL BOUNDARY IS DELINEATED.  Delineating a new control implies continuing output at the position where it would be if the window were using fixed fonts.

One of the disappointments in moving to a GUI presentation is that text selection via DATAHILITE overrides the ATTR value. ATTR still applies to the 'current' field (where the cursor is) once the data is deselected. But the color of selected text is necessarily determined by the operating environment. If you want to override the color of the current field immediately upon entry, then you will have to turn DATAHILITE off so the text will not be selected upon entry.

The new GUI mode does NOT permit bleed through the way the old console does. That is, anything written to an underlying window is not seen until the overlaying window is removed. However, a capability called FORCE VISIBILITY (described in a separate section) overcomes this limitation for programs designed for the old BR console.

If a field is written to a window that already has an overlapping field, then the field which it overlaps (the original field on the screen) is automatically deleted. There are a couple of exceptions to this:

:1.) LABELs printed to a window using a proportional font can sometimes extend beyond the area that they would occupy as a fixed width font. When this happens, BR extends the control (text space) to the length of the proportional data. If a label is subsequently displayed in this extended area, it is positioned *under* the previous label extension.  If a non-label is printed in this extended area, it is positioned *over* the label extension.

:2.) If a control is displayed over the top of a LABEL's fixed character space, the original label is stenciled (or truncated) by the new control using fixed width font logic. Each resulting segment is handled independently as if it were a separate field.

===Grid and List===
{{:Grid and List}}

===Tabs===

{{:Tabs}}

==Font Control and Color Specification==

===Attribute Substitution Name Extensions===

Field Attribute [xxx] identifiers may now be up to 12 characters long.

Fonts can be specified at the field level by assigning them to attribute substitution names as in:

 CONFIG ATTRIBUTE [hilite_text]  font=ariel:slant:max
 or -
 CONFIG ATTRIBUTE [hilite_text] /#rrggbb:#rrggbb, font=ariel:slant:max

This specifies that [hilite_text] denotes foreground and background colors specified as #rrggbb with ariel, italics, and maximum size font.

===Screen and Attribute Statements Working Together===

SCREEN statements can now use [config-attribute] references.  So the preferred (more readable) method for specifying screen attributes is to first define each attribute in full words and then reference them in SCREEN statements.  This means that the ATTRIBUTES and SCREEN statements can be used to progressively build upon one another:

:e.g.    ATTRIBUTES [lite_blue] /#112233:#556677 (This sets lite_blue foreground and background in terms of HTML color specifications.)

 ATTRIBUTES [yellow] /#442255:#887799
 SCREEN N [lite_blue], U [yellow]

   - or better yet -
 ATTRIBUTES [normal] /W:W    ! windows foreground and background
 SCREEN N [normal]

 ATTRIBUTES [XX] UH, font=ariel:slant:max
- or -
 ATTRIBUTES [XX] UH/RGB:W, font=ariel:slant:max

On Unix terminals the above statement would be interpreted as:

 ATTRIBUTES [XX] UH/RGB:
because W and font= are ignored by Unix terminal support.

Now that I have defined [XX] and other attributes I can specify:
 SCREEN N [lite_blue], U [yellow], R [XX]

The /xxx:yyy embedded syntax in FIELDS statements still overrides color for the corresponding fields, irrespective of SCREEN settings. However, now a W may be specified in lieu of R, G, B and H, denoting use the current Windows colors.<br>
e.g. /RG:W     -  yellow foreground on Windows background color

Colors may now be specified as /#rrggbb:#rrggbb where rr is the red gradient, gg is the green and bb is the blue gradient. Or they may be specified as /W:W which denotes Windows foreground and background.

The *background* color attribute T denotes Transparent and applies ONLY TO LABELS (PRINT FIELDS and INPUT SELECT). This is useful for printing text over various backgrounds without showing the Windows grey around the letters.

Examples:

 00080 Execute "CONFIG ATTRIBUTE [mickey_mouse] /#rrggbb:T, font=ariel:slant:max"

 00090 Execute "CONFIG ATTRIBUTE [hilite_text] /#rrggbb:#rrggbb, font=ariel:slant:max"
 00100 PRINT FIELDS "12,22,25/C 20,[hilite_text],520": "My Text"

This example displays up to 25 proportional characters in a 20 fixed character space in specific colors with ariel italics, maximum size, and a hot key (fkey) value of 520.

===Font Characteristics===

Multiple fonts are now supported under Windows.  The default is still SYSTEMPC.  Any installed non-proportional font is permitted that is named in the following BRCONFIG.SYS statement:

FONT {fontname} ...

Some of the fonts provided by Microsoft are:

Lucida Console<br>
Minitel<br>
Terminal (NT only)<br>
some Courier fonts

Version 3.9+ supports the command STATUS FONTS.  This will report all currently installed Windows fonts that are acceptable in a FONT statement.  Also fonts can be changed dynamically via the CONFIG command.

FONT=<br>
FONT.TEXT=<br>
FONT.LABELS=<br>
FONT.BUTTONS=

The default font is the user's Windows default font. Separate fonts may be invoked for Labels, Buttons, and Text (data entry fields):

 00100 OPEN #0: "Srow=5,Scol=5,Rows=25,Cols=80,FONT=Arial", Display, Outin
:|(specifies a base font)
 00200 OPEN #0: "Rows=30,Cols=100,FONT.LABELS=Terminal,FONT.TEXT=Arial,FONT.BUTTONS=Lucida Console", Display, Outin

You can also specify the following font qualifiers:

:1.) Family: decor / roman / script / swiss / modern (fixed)(this may be useful in addition to the font name for systems that don't have the specified font)
:2.) Boldness: light / bold
:3.) Style: ital / slant
:4.) Underline: under
:5.) Size: small / medium / large / max - Size is based entirely on font height.

Font Size Adjustment- adjusts the size of displayed text down to accommodate the horizontal space allocated for the text:
:1.) Width:  Determine the average caps + digits character width. Then reduce the font size until the number of characters times this average fits the BR field capacity.
:2.) Width+: Determine the average letter size considering both upper and lower case letters. Then apply the width limitation.
:3.) Width-: Make the font small enough to accommodate a string of capital W's.
:4.) NoWidth: Clear the Width adjustment setting.

 e.g.
 00100 OPEN #0: "Rows=30,Cols=100,FONT.LABELS=Terminal:bold:slant,FONT.TEXT=Arial,FONT.BUTTONS=Lucida Console",Display,Outin

The former FONTSIZE=99x99 parameter is only supported when GUI is OFF.

Note that the maximum length of configuration statements has been increased to 800 bytes.

Also any open window statement will inherit the attributes of the parent window, except that any new font specification (labels / text / buttons) will begin with the system defaults for that category.

===Hot Text===

Any FIELDS text may now generate a keyboard scancode when double clicked, similar to the way Buttons and the Combo Box graphic do.

Hot field fkey values may now be in the ranges:
*  0-99<br>
*  1000-9999<br>
A special hot-key value of 10000 denotes the Enter key, and generates a zero fkey value.

Linedraw can also be marked as HOT.

===HTML Color Parameters===

;RRGGBB, W, and T Color Specifications

Colors may now be specified as /#rrggbb:#rrggbb where rr is the red gradient, gg is the green and bb is the blue gradient. Or they may be specified as /W:W which denotes Windows foreground and background.

The *background* color attribute T denotes Transparent and applies ONLY TO LABELS (PRINT FIELDS and INPUT SELECT). This is useful for printing text over various backgrounds without showing the Windows grey around the letters.

;Examples:

 00100 EXECUTE "CONFIG ATTRIBUTE [hilite_text]/#442255:T font=arial:slant:max"
 00200 OPEN #0: "caption=mikhail, Picture=Matrix.ico:NORESIZE",display,outin
 00300 PRINT FIELDS "12,40,C 20/25,[hilite_text],80": "Text is twenty chars"

;Output:
[[Image:NEWC0015.jpg]]

This example displays up to 25 proportional characters in a 20 fixed character space in specific colors with arial italics, maximum size, and a hot key (FKEY) value of 80.<br>
IMPORTANT: Spaces are not allowed between the attribute substitution name [hilite_text] and the attribute combination /#442255:T.  However, spaces are allowed between the attribute substitution name and the font specification. Also, do not put a comma after the attribute combination /#442255:T.

===Command Console Colors===

The SCREEN C xx specification determines the foreground and background colors of the command console.

===Windows Color and Font Settings===

;The current Windows color and font settings may be retrieved:
[NEWCELL(icells2l.spc)]

;For a complete list of possible values and current settings type:

 STATUS ENV

==Graphical Interface==

{{:Graphic User Interface}}

==Menu Support==

{{:Menu}}

==Keyboard Responses==

[[Image:NEWC0044.jpg]]

GRID Navigation Mode: -----------------------------------------------<br>
[[Image:NEWC0046.jpg]]

GRID Edit Mode: -----------------------------------------------------<br>
[[Image:NEWC0047.jpg]]

===Conditional On Datahilite===

[[Image:NEWC0048.jpg]]

===Insert Behavior===
 
 Insert defaults to being on if datahilite is on and off if datahilite is off.  It can be configured separately.
 
===FKEY Value:===
:  90 Page up
:  91 Page down
:  99 Escape key
: 100 Right click (Help)
: 102 Up arrow
: 103 Down Arrow
: 104 Right Arrow (in Grid)
: 105 Up Field
: 106 Down Field
: 107 Field Overflow
: 109 Right Arrow
: 112 Home Key
: 113 End Key
: 114 Field Plus (Numeric Pad)
: 115 Field Minus (Numeric Pad)
: 116 Right Arrow field exit via right arrow positions to first char of next field similar to down arrow

:
==Display Buttons==

{{:Display Buttons}}

==Mouse Response==

(only effective during INPUT operation)

FKEY has two new values 200 and 201 that may occur on a field with an X attribute.  This may affect your programs.  These values are returned when the mouse is used to exit a field.

Mouse Buttons can be remapped with a brconfig.sys keyboard statement.

{| border="1" cellpadding="2"
| '''|| Single Left Click '''|| Double Left Click
|-
|Without X '''||Move Cursor '''||Move and Enter
|-
|With X '''||Exit Field with  201 Fkey Value '''|| Exit Field with 202 Fkey Value
|-
|}
<br>
These exits imply that the cursor will resume at the field that is clicked upon.

{| border="1" cellpadding="2"
| '''||Single Right Click '''|| Double Right Click
|-
| '''||Exit the field with Fkey Value of 100 (same as help key)'''||Move to new location and Exit the 100 Fkey Value
|-
|}

==Windows Clipboard Support==

Windows Clipboard Support (Cut, Copy, and Paste)

Windows Cut and Paste

Mark a string using [[Shift+Arrow]] keys, then<br>
[[Ctrl+X]] to cut the string to the Windows clipboard,<br>
[[Ctrl+C]] to copy the string to the Windows clipboard,<br>
[[Ctrl+V]] to paste the string from the Windows clipboard<br>
([[Ctrl+A]] replaces Ctrl+C for breaking into a program.)

The above are all standard Windows keystrokes for cut & paste. Cut and Paste may be used within BR and between BR and other applications.

If a field is highlighted, paste will only paste to that field. Otherwise, BR pastes one line per field, starting with the current field and to all subsequent fields, until the last field, or last line, whichever comes first.

{{Future|A future release will support the mouse for marking text.}}

==WBTerm Compiler==

Business Rules require a [[wbterm.out]] file which is produced by the wbterm compiler release 5.1 or greater. This is due to significant changes made to the way Business Rules can access scancodes from a terminal's keyboard. All old wbterm.in files should recompile successfully, but we urge you to edit any existing wbterm.in files to use the new syntax which is available. Since older versions of the wbterm.out file will not operate on this release, your wbterm.in file must be recompiled using this release 5.1 wbterm compiler.

The old method of showing scancodes in the wbterm.in file was to specify up to two significant hex digits followed by a value indicating the number of extra characters to throw away. While this method is still supported, it is not adequate for some machines such as the IBM RT, where some significant digits were being thrown away. This method allows you to specify up to 20 significant digits.

For example, on an AIX console, the F1 key returns the following values: 1B 5B 30 30 31 71. With the old method, this scancode would be specified in the wbterm.in file as F1=5B30,3;.

With this method, the string returned by this key is specified as F1=1B5B30303171;. This method also supports special characters such as \033 for escape, thus the F1 string could also be coded as F1="\033[001q". Note that the escape value ("1B" in the first example and "\033" in the second) is included in this method string, whereas it was not with the old method.

Support for remapping alphanumeric keys has also been added. For example, if you wish to remap a particular keystroke for a wbterm.in keyword, you may use the following format: F10="+";. This example would, of course, disable the use of the + key to type the "+" character, but this syntax can be useful for inserting the actual ASCII text that a key is returning.

{\b Color=5 Spec in WBTerm}

COLOR=5 has been added to the Unix/Xenix wbterm.in file (release 1.4 or greater) to support color consoles, particularly Interactive 386/ix and AIX consoles.

To learn how this  specification works, you must first understand that when COLOR=5 is specified, Business Rules will send color information to the operating system in the following escape sequence format:  esc[0;3c;4c(;h)(;b)m. In this sequence, 3c represents the foreground color, 4c represents the background color, and "(;h)" and "(;b)" are optional parameters for highlight and blink. Business Rules determines the values for c, h and b by referring to the COLOR=5 spec.

The format of the COLOR=5 specification is as follows:

COLOR=5, "cccccccchb";

The 10 positions in the above quoted string correspond to the 10 display attributes in the following IBM PC color table:

0 - black<br>
1 - blue<br>
2 - green<br>
3 - cyan (blue+green)<br>
4 - red<br>
5 - magenta (red+blue)<br>
6 - brown (red+green)<br>
7 - white (red+blue+green)<br>
8 - highlight<br>
9 - blink

To create the COLOR=5 specification for any terminal, you must order the first eight digits according to the way in which their colors appear in the terminal's color table (this information should be available in the terminal documentation). The last two digits identify the escape character that must be sent for highlight and blink, respectively. The following specification, for instance, indicates that black (0) is the first color in the AT386 color table, red (4) is the second, green (2) is the third, and so on. The last two characters in the string identify that 1 is the code to use for highlight, and 5 is the code to use for blink.

 COLOR=5, "0426153715";       ! actual AT386 entry

To display a red foreground on a black background, Business Rules would refer to the above COLOR=5 spec and note that red (4) is in the 1 position of the 10-digit string, while black (0) is in the 0 position of the 10-digit string. Therefore, it would send an escape sequence of esc[0;31;40m to the operating system. (It uses a value of 1 for the foreground c and a value of 0 for the background c values in the esc[0;3c;4c(;h)(;b)m character sequence.)

Likewise, to display a magenta foreground on a blue background with blink, Business Rules would see that magenta (5) is in the 6 position, blue (1) is in the 5 position, and that the value of the blink position is 5 in the COLOR=5 string. Therefore, it would send an escape sequence of esc[0;35;45;5m.

Some additional examples of escape sequences that Business Rules would send based on the above COLOR=5 spec for the AT386 are as follows:

esc[0;31;40;5m        - red on black with blink<br>
esc[0;35;40m          - red+blue on black<br>
esc[0;30;48;1m        - black on white with highlight

==Setting Display attributes with PRINT HEX$==

In addition to using full screen processing, there are two ways to set the display attributes on a screen: with the PRINT HEX$("1Bxx") method and with the PRINT HEX$("Ex") method. In all cases, a PRINT [[NEWPAGE]] statement clears the screen and sets all character attributes to normal. Some display combinations may not be supported on all machines.

===Print HEX$("1Bxx")===

;Visual attributes of the display screen can be changed by executing the following statement:

PRINT HEX$("1Bxx")

In this example, xx represents the machine-dependent hexadecimal representation of the display attribute. This method is not portable between equipment types. Once such a statement is executed, Business Rules uses the specified attribute for all screen output until a new PRINT HEX$("1Bxx") statement (or a PRINT NEWPAGE) is executed.<br>
The bit configuration for xx on the IBM PC is as follows:

[[Image:HELP0136.jpg]]

===Print Hex$("Ex")===

PRINT HEX$("Ex")<br>
Another method of setting visual attributes of the display screen is to execute the statement PRINT HEX$("Ex"), where x is:

{|border=1
|0||normal screen
|-
|1||underline
|-
|2||blink<br>
|-
|3||invisible
|-
|4||highlight
|-
|5||highlight underline
|-
|6||highlight blink
|-
|7||highlight blink underline
|-
|8||reverse
|-
|9||reverse underline
|-
|A||reverse blink
|-
|B||reverse blink underline
|-
|C||reverse highlight
|-
|D||reverse highlight underline
|-
|E||reverse highlight blink
|-
|F||reverse highlight blink underline
|}

Once the PRINT HEX$("Ex") statement is executed, Business Rules uses the specified attribute for all screen output until a new PRINT HEX$("Ex") statement (or a PRINT NEWPAGE) is encountered.<br>
This method is not fully portable between equipment types -especially A to F.

===Icon===
 SETENV("ICON","myicon.ico") sets the icon for the window and the taskbar to the icon specified by the second parameter (e.g. myicon).

===Graphical Console===

A new keyword, FONTS, has been added to the STATUS command that lists installed fonts that are suitable for use with BR.

The OPEN #0: string can contain the keyword MAXIMIZE or NOMAXIMIZE which will override the user's INI settings.  If not specified, the "Save Font Size And Position" settings will govern.

{\b COMBO BOX GRAPHIC AND HOT TEXT}

PRINT FIELDS "row, col, C 10, Q,X02":  "Box Caption" will place a graphic combo box down arrow graphic to the right of the field.  When the field is double clicked, a HEX 02 keyboard character is generated.  The X02 could also be a four digit hex value (X5044) or a function key number (14).

==KEYBOARD CHANGES==

The significance of certain keyboard characters has been revised:
* = changed<br>
^ = with control key pressed

  ^A - break ( this was ^C )<br>
  ^B - page up (back)<br>
  ^C - copy to clipboard<br>
  ^D - delete<br>
  ^E - end field<br>
  ^F - page down (forward)<br>
  ^G - backtab<br>
  ^H - backspace<br>
  ^I - tab<br>
  ^J - next field<br>
  ^K - prior field<br>
  ^L - right arrow<br>
  ^M - enter<br>
  ^N - left arrow<br>
  ^O - field minus<br>
  ^P - print screen<br>
  ^Q - toggle insert mode<br>
  ^R - up field (rise)<br>
  ^S - toggle hold mode (stop)<br>
*  ^T - down field ( this once was ^V )<br>
  ^U - field plus<br>
  ^V - paste clipboard content<br>
  ^W - home<br>
  ^X - cut to clipboard<br>
*  ^Y - was REPAINT SCREEN in Unix - now HELP  (back where it was)<br>
    unchanged in Windows - still HELP<br>
  ^Z - restore field<br>
  ^[ - escape<br>
  ^\ - toggle translation of numerics to linedraw characters<br>
*  ^- - REPAINT SCREEN ( this once was ^X )<br>
    use the minus key on the top row of the keyboard<br>
    along with the control key

INPUT SELECT now displays lines like PRINT FIELDS.

==Label Alignment==

[[Image:NEWC0001.jpg]]

Labels (captions) displayed are analyzed for spacing.  If more than one blank is found or line draw or underline characters are encountered (denoting a text field), a new control is delineated, which means that the label is split in two or more pieces.

When such individual controls (label segments) are delineated the last non-whitespace character of each subfield is checked for a colon.  If it is a colon the text is right justified within the subfield.  In other words, the colon right aligns the data where it would be if fixed width fonts were used.

The name of this example is: DELINEAT.BR

 00100 PRINT FIELDS "1,1,C 10" : "one two"    ! treated as a single label (one space in between)
 00200 PRINT FIELDS "2,1,C 10" : "one   two"    ! treated as two separate labels (three spaces)
 00300 PRINT FIELDS "3,1,C 10" : "one:  two"    ! treated as two separate labels (two spaces)!:! label "one" will be right justified in a 4 position subfield
 00400 PRINT FIELDS "4,1,C 10" : "one   two:"    ! treated as two separate labels (three spaces)!:! label "two" will be right justified

;Output:

[[Image:NEWC0002.jpg]]

In the output of line 200 in the above example, "two" is left aligned where it would be if a fixed font were used.

Proportional font characters have varying widths.

In the following example, when a proportional font is used, the word "row" looks longer than the word "big" and the word "bit", but the words "column", "object", and "locate" will still line up with each other when printed to the graphical console.  This is because positioning and sizing of controls on the window are managed by simulating fixed character positions.

The name of this example is: PROPFONT.BR

 00100 PRINT FIELDS "1,1,C 30": "Row         Column"
 00200 PRINT FIELDS "2,1,C 30": "Big         Object"
 00300 PRINT FIELDS "3,1,C 30": "Bit         Locate"

;Output:

[[Image:NEWC0003.jpg]]

If proportional fonts are turned off by executing CONFIG GUI OFF, then each letter will be exactly the same height and width as all other letters. The above example will then produce the following output:

[[Image:NEWC0004.jpg]]

If a CHR$(5) character is encountered with proportional fonts on, it is replaced by a blank and a control boundary is delineated.  Delineating a new control implies continuing output at the position where it would be if the window were using fixed fonts. In other words, using CHR$(5) simulates fixed character positions and makes label "iiii" and label "wwww" have the same width.

The name of this example is: CHR5.BR

 00100 PRINT FIELDS "1,1,C 10": "iiii wwww"
 00200 PRINT FIELDS "2,1,C 10": "iiii"&CHR$(5)&"wwww"

;Output:
[[Image:NEWC0005.jpg]]

One of the disappointments in moving to a GUI presentation is that text selection via DATAHILITE overrides the ATTR value. ATTR still applies to the current field (where the cursor is) once the data is deselected. But the color of selected text is necessarily determined by the operating environment. If you want to override the color of the current field immediately upon entry, then you will have to turn DATAHILITE OFF, so the text will not be selected upon entry.  So, if the ATTR specification is to be honored, then the new GUI should be run with DATAHILITE OFF.

The new GUI mode does not permit bleed through the way the old console does. That is, anything written to an underlying window is not seen until the overlaying window is removed. However, a capability called FORCE VISIBILITY (described in a separate section) overcomes this limitation for programs designed for the old BR console.

If a text field is written to a window that already has an overlapping text field, then the text field, which it overlaps (the original text field on the screen) is automatically deleted.

The name of this example is: OVERLAP.BR

 00100 PRINT FIELDS "1,1,C 5,,B20": "ooooo"  ! this button will be automatically deleted
 00200 PRINT FIELDS "1,5,C 2,,B40": "xx"    ! this button overlaps the first one and causes the first field to be deleted

;Output:
[[Image:NEWC0006.jpg]]

There are a couple of exceptions to this:

:1.) Labels printed to a window using a proportional font can sometimes extend beyond the area that they would occupy as a fixed width font. When this happens, BR extends the control (text space) to the necessary length. If another label is subsequently displayed in this extended area, then it is positioned under the previous label extension.  If a non-label is printed in this extended area, it is positioned over the label extension.

The name of this example is: OVERLAP2.BR

 00100 PRINT FIELDS "1,1,C 8" : "SSSSSSSS"     ! label
 00200 PRINT FIELDS "1,9,C 4": "oooo"    ! this label is positioned under the previous label
 00300 PRINT
 FIELDS "2,1,C 8" : "SSSSSSSS"  ! label
 00400 PRINT FIELDS "2,9,C 4,,B5": "oooo"     ! this button is positioned over the previous label

;Output:
[[Image:NEWC0007.jpg]]

:2.) If a control is displayed over the top of a label's fixed character space, the original label is truncated by the new control using fixed width font logic. Each resulting segment is handled independently, as if it were a separate field.

The name of this example is: OVERLAP3.BR

 00100 PRINT FIELDS "1,1,C 8": "abcdefgh"    ! this label is 8 character long
 00200 INPUT FIELDS "1,1,C 4": VAR$    ! this control is over the top of the previous label's fixed character space and causes the label to be separated into two pieces

;Output:
[[Image:NEWC0008.jpg]]

==New Features-==

===Inactive Fields===
Normal windows behavior is to dim inactive fields.  This can be overridden with the [inactive] attribute, which refers to inactive graphical controls. The attribute names are not case sensitive.

e.g.     CONFIG ATTRIBUTE [inactive]/#112233:#445566

===Menu improvements===
The way menus are displayed has been improved with respect to speed and appearance. The R (retain) menu flag is now honored.

===Hot Controls - Focus===
Any control with an FKEY associated with it via the PRINT FIELDS statement will remain hot at all times, irrespective of whether it is participating in an INPUT FIELDS operation.

[NEWCELL(icells3l.spc)]
===Paste behavior and Navigation Keys===
;Paste behavior
{| border="1" cellpadding="2"
|Action'''||Old'''||New'''||
|-
|Ctrl-V'''||paste goes into multiple fields at line endings'''||the current field gets the data it can take'''||
|-
|left/right arrows '''||cause a field exit at beginning and end of field '''||arrow keys stop at end of field'''||
|-
|up/down arrows'''||prior/next field'''||the same as left and right'''||
|-
|}
;Navigation Keys
{| border="1" cellpadding="2"
|Action'''||Old'''||New'''||
|-
|up/down'''||up/down cell'''||up/down cell'''||
|-
|left/right'''||left/right cell'''||left/right cell'''||
|-
|Home/End in GRID'''||get focus '''||set cursor'''||
|-
|left/right'''||cause a field exit at '''||'''||arrow keys stop at end of field'''||
|-
|}
===Data entry in a Grid===

==INTERNAL PROCESSING CHANGES==
===WSID 0 No longer allowed===

WSID 0 is no longer allowed. The priority of WSID assignment is:
:1.) Command line WSID requests take precedence over brconfig.sys WSID statements.
:2.) Of the brconfig.sys WSID statements, the last one specified is used.

==NEW AND EXTENDED FEATURES==

The I field attribute represents invisible. Under Windows it is now treated as a password field. Most typically it is displayed as a string of asterisks (e.g. *****).

Long filenames may now be up to 512 characters in length.

===Clipboard Access===

{{:Clipboard}}

==New Status Commands==
[NEWCELL(icells1l.spc)]




===STATUS and Partial Filename===

BR now supports partial filenames on the STATUS FILES and STATUS LOCKS commands:
[NEWCELL(icells1l.spc)]

==BUG FIXES==
The text portion of Combo Boxes can now be used as ordinary FIELDS as in:

 01010 INPUT FIELDS "5,10, C 12; 7,10,COMBO 15; 9,10,C 8": MAT DATA$

Formerly, the statement had to read:

 01010 INPUT FIELDS "5,10, C 12; 7,10,COMBO 15; 9,10,C 8": DATA$(1),DATA$(2),DATA$(3)

DIM statements were not being reinitialized prior to Save and Replace operations. This caused arrays to be corrupted when they were redimensioned in a library routine prior to replacing a program. This was an ancient bug.

[[Category:Basics]]