NoFiles

The NoFiles parameter for Library statements was introduced in version 4.20 of Business Rules!.

LIBRARY [RELEASE] [,NOFILES] [file-ref] : FNxxx, ...

To handle situations where the program and the library function it calls use the same file handles for open files, windows etc.

When this optional parameter is used, it allows your program and the library function to use the same file handles without causing an error. You can call and use the function without passing the files back and forth.

A library initiated with NOFILES has it's own file set, and calls to it do not inherit any open channels. Each program library statement either indicates NOFILES or defaults to FILES. A library that is active as NOFILES cannot be passed files and vice versa. A library that is passed two different sets of files (by separate calls) simply works with what it is passed.

When LIBRARY NOFILES is specified, a separate console (window #0) is also created to service the library. The new console's size and properties are taken from the initiator's current console. This new console does not become visible until a program attempts to await operator input. Each NOFILES library has its own console regardless of GUI state.

When a LIBRARY statement is processed without the NOFILES parameter then a new console is not created and screen operations pertain to the caller's window hierarchy.

Inactive RELEASEd modules can be linked in either NOFILES mode (defaulting to FILES or specifying NOFILES) irrespective of previous modes of use and whether or not they were loaded resident.

NOFILES works with GUI OFF but PARENT=NONE is illegal with GUI off. If a program switches GUI modes, it does not affect any other independent console hierarchies. So it is possible to mix GUI modes with different window hierarchies each having it’s own GUI mode.

Files opened NOCLOSE by NOFILES libraries are opened as normal files. In such cases the NOCLOSE parameter is ignored.

Positioning of Independent Windows

When an independent window is maximized the actual window edges slightly exceed the screen border. This is normal Windows behavior. Child windows are positioned in relation to the useable rectangles of their parents.

SROW and SCOL specify the Usable Rectangle position. Therefore extra border rows and columns must be specified to allow for framing when a border is required or the window is a tabbed window. In other words a framed window should be positioned one column to the right and one row below where the frame will appear.

Example

Example Program- (cut and paste into a text editor – then LOAD file SOURCE)

00010    def FNRECTSTRING$*100(MAT RECT)="x="&STR$(RECT(1))&", y="&STR$(RECT(2))&", width="&STR$(RECT(3))&", height="&STR$(RECT(4))
00020    def FNPRINTSCREENINFO(WINDOWNUMBER)
00030       let FILE(WINDOWNUMBER, "WINDOW_RECT", MAT RECT)
00040       print #WINDOWNUMBER, fields "1,1,c": "window rect is "&FNRECTSTRING$(MAT RECT)
00050       let FILE(WINDOWNUMBER, "USABLE_RECT", MAT RECT)
00060       print #WINDOWNUMBER, fields "2,1,c": "usable rect is "&FNRECTSTRING$(MAT RECT)
00070       let FILE(WINDOWNUMBER, "FONTSIZE", MAT RECT)
00080       print #WINDOWNUMBER, fields "3,1,c": "font size height="&STR$(RECT(1))&", width="&STR$(RECT(2))
00090    fnend 
00100    open #1: "srow=4,scol=4,rows=3,cols=70,n=/rgb:b",display,output 
00110    open #2: "srow=8,scol=4,rows=3,cols=70,n=/hrgb:r,font=roman,border=s,caption=window info",display,output 
00120    open #3: "srow=12,scol=4,rows=12,cols=70,n=/g:b",display,output 
00130    open #4: "parent=3,srow=4,scol=1,rows=3,cols=65,n=/r:g",display,output 
00131    open #5: "parent=3,srow=8,scol=2,rows=3,cols=65,n=/r:rgb,font=roman,tab=one",display,output 
00140    let FNPRINTSCREENINFO(0)
00150    let FNPRINTSCREENINFO(1)
00160    let FNPRINTSCREENINFO(2)
00170    let FNPRINTSCREENINFO(3)
00180    let FNPRINTSCREENINFO(4)
00181    let FNPRINTSCREENINFO(5)
00190    let KSTAT$(1)