Have a Question?

00619: Read.me file for PRO/5 rev 1.05


Read.me file for PRO/5 rev 1.05


Part 1 

README for PRO/5 (TM) and Visual PRO/5 (TM) REV 1.05 
                  BASIS International Ltd. 
June 17, 1997 


1. Introduction to PRO/5 
2. Moving to PRO/5 
3. SYSPRINT Enhancements 
4. SQL Capabilities 
5. PRO/5 Release Notes (some apply to Visual PRO/5) 
6. Visual PRO/5 Release Notes 
7. Resource Editor Release Notes 
8. Novell NetWare 
9. In-Place DIRECT to MKEYED File Conversion 
10. Known Problems 


PRO/5 and Visual PRO/5 REV 1.05 represent the next generation of Business BASIC interpreter and Data Server products from BASIS International. PRO/5 is compatible with BBxPROGRESSION/4 (R), and Visual PRO/5 is compatible with BBxPROGRESSION/4 for Windows. In addition, many new features have been added. 

PRO/5 and Visual PRO/5 now offer: 

        * SQL database access on many popular platforms 

        * 16-digit math precision (in BBxPROGRESSION/4 was 14-digit) 

        * Data integrity assurance with file Auditing and 
         Transaction Tracking 

        * SWITCH..CASE..SWEND verbs 

        * The BREAK and CONTINUE verbs allow better looping control 

        * New functions for run time expression evaluation 

        * Support for programs up to 1MB in length 

Visual PRO/5 now offers: 

        * Fully customizable GUI subsystem 

        * Smarter terminal: scroll bars, and many more mnemonics 

        * DDE text communications 

        * A Window “screen dump” printing feature 

        * A Graphical Resource Editor 

        * Large start sizes 


If you are moving your computing environment from BBxPROGRESSION/4 to PRO/5, a few issues to be aware of: 

* PRO/5 can read and execute portable BBxPROGRESSION/4 programs with no changes or conversion of any kind. However, if changes are made to a BBxPROGRESSION/4 program, and the program is then saved from within PRO/5, the newly-saved program becomes a PRO/5 program which will no longer run under BBxPROGRESSION/4. It is still possible to move it back to BBxPROGRESSION/4, using LIST and MERGE, or the stand-alone compiler and lister tools, provided that no PRO/5-specific features have been added to the program. 

* BBxPROGRESSION/4 and PRO/5 may be used together without file sharing conflicts. It is not necessary to use the floating lock byte SETOPTS bit, since BBxPROGRESSION/4 and PRO/5 use different locking regions. Also, there will be no conflicts with the shared memory and semaphore vectors under UNIX systems, or with the bindery objects under Novell NetWare systems. PRO/5 will not clash with BBxPROGRESSION/4 in these areas. 

* A PRO/5 client cannot communicate with a BBxPROGRESSION/4 Data Server (R), nor can a BBxPROGRESSION/4 client communicate with a PRO/5 Data Server (TM). The server and client must be upgraded together. PRO/5 and BBxPROGRESSION/4 Data Servers may coexist on the same machine without any conflicts. 

* In most cases, the increase in mathematical precision from 14 to 16-digits will not produce noticeable effects in the execution of your programs. In the few cases where it would, it is expected that the resulting increase in accuracy would be desirable. However, if you have any math tests in your programs, where computed values are compared against previously-computed values, be aware that these could be different. For example, if a BBxPROGRESSION/4 program computes 5/9, the result is 5.5555555555556E-1, for PRO/5 the result would be 5.555555555555556E-1. If the result of a computation is saved in a file and checked or recomputed later, the upgrade to PRO/5 might cause the check to fail or the recomputation to yield a slightly different answer. 

* The increase in mathematical precision can also affect any MKEYED files that have keys with the “B” flag (business math key) set, or that have data written to them from a string template with a field type of “B”. A SETOPTS bit (byte 4, bit $08$: $00000008$) has been added to select compatibility with BBxPROGRESSION/4 in these areas: 

         Without the SETOPTS bit, PRO/5 can read BBxPROGRESSION/4 template data correctly but might possibly write out numerical data with extra precision, so that BBxPROGRESSION/4 can no longer retrieve the data. If BBxPROGRESSION/4 continues to share data files with PRO/5, it is necessary to keep this bit on. 

         Without the SETOPTS bit, keys with the “B” flag set in data files written from BBxPROGRESSION/4 will read out-of-order. Turning the bit on will maintain compatibility with BBxPROGRESSION/4’s business math (“B” flagged) keys. 

         If files with any “B” keys and/or template data with “B” fields in them are to be shared between BBxPROGRESSION/4 and PRO/5, turn this SETOPTS bit on. 

         If you plan to make a clean switch from BBxPROGRESSION/4 to PRO/5, you do not need to worry about any template data with “B” fields in them, as PRO/5 will read the old data correctly. “B” flagged keys are still a concern, since they will read out-of-order without conversion. To solve this problem, you can either not have the extra precision in the keys (often this is acceptable), by just turning on the SETOPTS bit. Or, if you need the full 16-digit precision in your “B” keys, follow one of two procedures: 

                 1. Copy all the data to a new file, keeping the SETOPTS bit off. 


                 2. Use a key chain without the “B” flag, 
                  For each record… 
                          Turn SETOPTS bit on 
                          Read record 
                          Remove record 
                          Turn SETOPTS bit off 
                          Write record 
                  Move to next record. 


* Each time the SYSPRINT device is opened, a list of all fonts and sizes which is acceptable to the selected printer is placed in FIN(chan,IND=2). The template for this data is returned using the TMPL(chan,IND=2) function. Only fonts which are fixed width and not italicized or strikeout are considered. 

* FIN(chan,IND=1) on a SYSPRINT channel now returns: the physical pixel counts on the device for the offset to printing area, printer physical pixel width and height, font width and height, the printing area width and height and the current selected font face name. The template for this data is returned in TMPL(chan,IND=1). 

The template currently has this format: 


xres is the number of printable pixels (or dots) available horizontally on the print page. This value will be smaller than yres if the page is portrait. It will be larger if the page is landscape. This value does not include any unprintable areas defined by the printer/print driver. It is in printer units. 

yres is the number of printable pixels (or dots) available vertically on the page. This value does not include any unprintable areas defined by the printer/print driver. It is in printer units. 

xppi is the number of pixels (or dots) per inch on the horizontal as defined by the printer for the page. 

yppi is the number of pixels (or dots) per inch on the vertical as defined by the printer for the page. 

xoffset is the value returned by the print driver for the unprintable area of page. This value is for the horizontal dimension and specifies the printer units on either side of the page that are not printable. 

yoffset is the value returned by the print driver for the unprintable area of page. This value is for the vertical dimension and specifies he printer units on either side of the page that are not printable. 

pwidth and pheight are similar to xres and yres but include the unprintable areas of the page. You can compute the dimensions of the page in inches by dividing these values by xppi and yppi, respectively. 

char_width and char_height are the current values being used by the interpreter for computing character and line spacing, respectively. These values are based on either the last font selected using the ‘FONT’ mnemonic or on the values of COLS and ROWS/LINES given on the alias line. If COLS and ROWS/LINES were not used but SPCOLS, SPLINES , EPCOLS, EPLINES, CPCOLS, and CPLINES were used instead, then the char_width and char_height is computed based on the fonts selected for these modes and the values reported will depend on what mode was selected by the software before retrieving the FIN() information. 

pagepos is the current line position on the page that will be used for the next printed output. The is a zero based value, zero is the top margin of the page. 

tmargin and lmargin specify the top and left margins for the first line of the page, respectively. If no top or left margin is specified, they default to the unprintable area reported by the Windows printer driver. These values are in device coordinates. 

font is the current font being used for printing. 

* The FONT= SYSPRINT mode has been reworked. FONT=SYSTEM and FONT=DEVICE are obsolete. FONT=<fontname> is now used, and any font valid for the device (such as those enumerated in FIN(chan,ind=2)) may be used. For example: 

        ALIAS LP SYSPRINT “printer” dialog,font=”Courier New” 

This forces a particular font to be used, and the number of available columns and rows is determined by the page size available to the Windows driver. 

* Four new modes have been added to provide additional control over the SYSPRINT device: COLS=<val>, ROWS/LINES=<val>, TMARGIN=<val>, and LMARGIN=<val>. 

COLS and ROWS/LINES set the CP and SP values at the same time. Most programs really only want one value, and forcing the system to choose two fonts when one would do causes the interpreter to resort to slower TrueType fonts, even when a faster device font is available. For example: 

ALIAS LP SYSPRINT “printer” dialog,cols=80,rows=66 

If COLS= and ROWS= are specified, and FONT= is not, the number of columns and rows will match the number requested. The interpreter will use the best available device font to fit, given the page area available from the driver. If no font can be found to provide the requested number of columns and rows,!ERROR=1 is returned on the OPEN. 

If COLS=, ROWS=, and FONT= are specified, the interpreter will attempt to find the closest match to all three parameters, without guaranteeing that any of them will match the requested values. 

TMARGIN and LMARGIN specify the top and left margins of the page. This is where the first line of the page will begin. 

* Three new mnemonics have been added to help software control the printed output: ‘TMARGIN'(val), ‘LMARGIN'(val), and ‘ENDSPOOL’. ‘TMARGIN’ and ‘LMARGIN’ take a decimal value in inches which specify the starting position of the first line on the page. Do not use these mnemonics except at the start of a given page as they adjust the page position at the time they are encountered. 

‘ENDSPOOL’ takes no parameters and forces a Windows print job without software having to do a CLOSE(chan). The advantage is that the print job which does alignment first does not have to reset the printer after alignment parameters are adjusted correctly which a CLOSE(chan) forces software to do. 


* Three new options have been added to the SQL.INI file. 


        This causes a log file to be created. It records information about connections and errors.


        This turns off the ability to access ODBC databases. The native BASIS SQL Engine is still operational. 


        This disables the native BASIS SQL Engine. ODBC access is still operational. 

        Supplying both ODBC=0 and TAOSDB=0 disables all SQL capability. 

* Five new modes have been added to SQLOPEN. 


        Supplies a user name to be used with the current data source. 
        For example: 

                 SQLOPEN(1,MODE=”UID=fdanman”) “Hotel Data” 


        Supplies a password to be used with the user name set by 
        the UID mode. For example: 

                 SQLOPEN(1,MODE=”UID=fdanman,PWD=xyzzy”) “Hotel Data” 

        Not all data sources require UID and PWD. 

DSN=<data source name string> 

When a data source requires more than UID and PWD as data source keywords, they can be passed in the SQLOPEN data source name string. For example: 

                 SQLOPEN(1)”DSN=Hotel Data;UID=fdanman;FTY=1;NTW=pctcp” 

        The data source name must follow the DSN keyword. All other keywords are driver-specific. 


        By default, PRO/5 uses the ODBC SQLConnect function to connect to a data source when SQLOPEN is used. This mode specifies that SQLDriverConnect is to be used instead. Example: 

         SQLOPEN(1,mode=”SQLDriverConnect”) “MS Access 7.0 Database” 

        SQLDriverConnect provides an interactive connection mechanism         that is controlled by the ODBC Driver Manager. Not all drivers support SQLDriverConnect. 

        Only connections to data sources that are defined by the ODBC Driver Manger will be considered for connection by PRO/5. In other words, you should not use SQLDriverConnect to connect to a driver directly. Always specify the data source name when using SQLDriverConnect. 


        This mode is not required unless there is a bug in the ODBC Driver you are using. Certain Microsoft drivers have a bug         that causes all result columns to have the same value (that of the first column). If you have such a driver, report this problem to the supplier. Until you receive the fix, this is the mechanism to work around the bug. 

         SQLOPEN (1,MODE=”ExecDirect=1″) “MS Access 7.0 Database” 

        This mode switch causes the ODBC SQLExecute function to be replaced by SQLExecDirect. This will slow the performance of PRO/5 in conjunction with this driver. 

* SQLERR now returns error codes from unsuccessful SQLOPEN attempts. 

* SQLOPEN no longer accepts a channel number of 0. 

* SQLTABLES can no longer cause a release. 

* The manuals incorrectly document the SQLSET verb as SQLARG. 

* The previously undocumented PRO/5 error code !ERROR=77 is a general SQL error code. For specific information on a particular error, check SQLERR(). 

* ODBC data type SQL_TIME is retrieved by PRO/5 as a floating point number representing hours, similar to the TIM system variable. 

* ODBC data type SQL_DATE is retrieved by PRO/5 as a Julian date. 

* PRO/5 provides no support for timestamp type data. 

* The SQLFETCH() and SQLTMPL() functions have been enhanced. SQLFETCH(chan,ind=1) now returns the result set count. SQLTMPL(chan,ind=1) retrieves a template for that data. 

* Querying MS Access Yes/No fields will return a C(1) value, not a numeric value. 

* MS Access variable length memo fields cannot be imported into PRO/5 templates. 

5. PRO/5 RELEASE NOTES (also applicable to Visual PRO/5) 

Changes from Revision 1.04 to Revision 1.05: 

* A problem in the MKEYED file driver with multi-keyed MKEYED files reporting incorrect key values for KNUM greater than 1 has been fixed. 

* SETOPTS Byte 4, Bit $08$ is now correctly interpreted by PRO/5. 

* DOS 386 Single-user and multi-user versions require the use of SHARE.EXE to avoid memory errors. This does 
not apply to the PRO/5 DOS 386 NetWare version. 

Changes from Revision 1.03 to Revision 1.04: 

* The INFO(3,3) function now reports the correct USERDESC information. INFO(3,3) returns the value of USERDESC if the user description cannot be found in the UNIX password file or the Novell login information. 

* The PRO/5 Commands Manual, page 264, states that the SWITCH verb can take any valid integer expression. The build of PRO/5 Revision 1.04 ensures that the statement is true. Previously, the expression range was from 0 to 32767. 

* A problem in the Auditing system was fixed that cause illegal operations or core dumps when the same piece of code was run more than once. 

* Under certain error conditions using the NEVAL() and SEVAL() functions, PRO/5 would fail to recover correctly, resulting in a core dump or illegal operation. Error conditions with NEVAL() and SEVAL() are now handled correctly. 

* The INFO(3,0) function now returns the correct unique task ID. This fixes a problem on AIX. 

* An error using the FILEOPT verb without the first parameter being “TTS” has been fixed. If the first parameter is not “TTS” an !ERROR=17 is reported. 

* Better caching has been added in Revision 1.04 of PRO/5 and Visual PRO/5 to enhance the performance of the MKEYED file driver on systems where caching isn’t supplied by the native operating system. DOS, Windows, and Novell in particular should have improvements in performance. 

* SQL statements that produce no result set will no longer get a strange error that was a result of binding columns that were not there. 

* PRO/5 no longer calls SQLSetParam – an ODBC 1.0 function that was phased out in ODBC 2.0. It now calls SQLBindParameter. 

* The problem where fields that were set with SQLSET() would “bleed” into each other when more than one value was set has been fixed. 

* PRO/5 now maps SQL_VARCHAR values to variable length strings. It places terminators on the fields and creates a field description. For example: 


Note that this may cause problems when dealing with non-ASCII data. 

* Added a call to math library function fpsetrnd() to set rounding to round-toward-zero mode for the HPUX systems. This fixes a problem with the BIN() function in the test case of PRINT BIN(2^6,1). 

* Using BREAK from a multi-nested FOR loop was causing an !ERROR=18. It now correctly breaks from multi-nested FOR loops * Revision 1.04 contains the enhancement for doing a SCALL() on UNIX. If a call to /bin/sh fails because that flavor of UNIX no longer puts ‘sh’ in /bin, then the “SHELL” environment variable is used to determine what shell should be used for the SCALL(). If successful, it uses the value for the name of the command to execute the users command. If the “SHELL” variable isn’t found, then PRO/5 exits with a status of -1. 

Changes from Revision 1.01 to Revision 1.03: 

* When using the Generic Text Printer Driver in Revision 1.01, Visual PRO/5 would cause a fault due to an invalid memory access. This problem was corrected for Revision 1.03. 

* The ERRMES() function’s syntax now correctly recognizes the string argument as an optional parameter. 

* When SETOPTS bit $00000080$ is set, Visual PRO/5 now correctly allows you to erase a file on a drive other than the current drive. 

* The file system now provides improved protection against corrupted files. 

* Visual PRO/5 now handles dates past the year 2000. 

Changes from Revision 1.0 to Revision 1.01: 

* REV 1.01 of the PRO/5 Data Server now permits up to nine connections per Windows Client workstation to count as a single licensed connection. 

* The new SEVAL() and NEVAL() functions no longer cause a GPF when passed invalid syntax. 

* The pro5plot utility now verifies that the release of X11 is greater than or equal to 5, not just that it is equal to 5. 

* It was possible to place a comment on the same line as the DEF of a multiline user defined function definition. This was not valid syntax and could lead to run-time errors. 

* A problem with the ENTER verb on the DEC Alpha has been fixed. 

* The PREFIX setting now has a maximum length of 512 characters. 

* The MKEYED file driver has improved error detection capabilities. If you are still getting !ERROR=7 reports after this upgrade, it is not because REV 1.01 is corrupting your files. Rather, REV 1.01 has the ability to detect corruption which may have gone unnoticed previously. If you suspect file corruption, refer to a recent backup or try the “_fix” utility. 

* PRO/5 is now able to execute BBxPROGRESSION/4 syntax in FATTR(REC$,”field”,””) 

* The function key and edit key translation buffers are now 512 bytes in size. This eliminates !ERROR=33 reports on ‘FL’ and ‘EL’ calls. 

* Under DOS, <Ctrl><Break> was left trapped during a system call, potentially causing a crash if <Ctrl><Break> was operated in a subshell. This has been fixed. 

* Under DOS, it is now possible to get a correct error code report from a system call, provided that the complete name of the executable is supplied (e.g., A=SCALL(“XCOPY.EXE FILE1.TXT FILE2.TXT”)). 

* With REV 1.0, if a RENAME was attempted via a PRO/5 Data Server, and the second file already existed, PRO/5 would erroneously continue to search the PREFIX for the first file. This has been fixed. 

In order to realize the benefit of the fix, it is necessary to upgrade both the PRO/5 Data Server and the client PRO/5 to REV 1.01. 

* In certain situations where Data Server connections were refused, socket resources were not always returned to the operating system. This has been fixed. 

* If insufficient memory is available to return a template on a SELECT channel, the FIN() function now returns the expected error code of !ERROR=33. 

* The CHANOPT() function now behaves correctly when used with a SELECT channel. 

* The DAY variable now behaves correctly when confronted with years greater than 1999. (e.g., The year 2000 is represented as “00”, not “:0”.) 

* SELECT no longer fails if the template provided exceeds 32KB in size. The SELECT template size limit is now 64KB. 

* On UNIX platforms, the WAIT verb is now interruptible. 

* Several new CHANOPT modes have been added which apply to serial communications ports. Add a minus sign (-) to the beginning of a mode to disable it. 

MODE UNIX Windows Description 
XON Y          Y send xon/xoff 
XOFF Y          Y respond to xon/xoff 
XON/XOFF Y          Y both of above 
XANY Y N respond to any char as xon 
CLOCAL Y          N use modem control signals 
CTS N          Y use CTS flow control 
DSR N Y use DSR flow control 

* All error reports (both fs load error and !ERROR= reports) provide more detail. 

* FILEOPT “TTS” with no additional arguments no longer generates an error condition. 

* Problems with Transaction Tracking involving the AUDITUSER feature have been fixed. 

* The second byte returned by the TSK() function will have the high bit ($80) set if the associated lock file already exists. This has not been previously documented. 

* PRO/5 Data Server REV 1.0 would log the third byte of the remote IP address incorrectly. The problem was actually in the client PRO/5, and it has been fixed in REV 1.01. 

* A new set of global string table entries are recognized, to provide security for applications wanting to grant partial console access. 

stbl(“!CONEXIT”) PRO/5 exits next time application stops running 
stbl(“!CONMESS”) defines message given before exit 
stbl(“!CONPASS”) defines password for console mode (“release” always exits) 

* A new function, ERRMES(int{,str$}), returns the error message associated with a given error code. Currently, the optional str parameter is not used. It may be used in the future to supply replacement error message text. 

* Under DOS, PRO/5 REV 1.01 now reserves 128 file handles from the operating system to permit more concurrent file opens. 

* The FIN() function now reports the date on a file correctly. 

* On UNIX platforms, PRO/5 REV 1.01 fixes a problem in the INITFILE verb where the path name points to a file opened via DSKSYN. 

* On multikeyed MKEYED files, any KEY= parameter supplied on a WRITE is ignored. 

* A new SETOPTS bit (byte 4, bit $80$) limits the search performed during an attempt to open a file. Normally all available disks are tried with all available PREFIX values that don’t include disks. With this option, the PREFIX is scanned only once, and any entries that have no disk are attempted with the current disk only. 

* String template fields of type “X” (machine-specific floating point format) weren’t always retrieved correctly in REV 1.0. This was fixed in REV 1.01. 


Part 2 


Changes from Revision 1.03 to Revision 1.04: 

* The Sysprint device now supports print slewing correctly. 

* Under a previous build of Visual PRO/5, Revision 1.04, opening a COM device would fail with an !ERROR=12. This problem has been fixed. 

* The ‘CLEAR’ mnemonic now works correctly on windows that are created maximized. 

* Visual PRO/5 running under Windows 3.1 or Windows 3.11 requires WIN32s revision 1.30 or higher. It replaces revision 1.25, which was previously shipped with Visual PRO/5. 

* The installation routine no longer prompts the user to install Win32s if the user is not running WINDOWS 3.1 or WINDOWS 3.11. 

* On single-user Visual PRO/5 products an !ERROR=0 occurs when a file open attempt is made to a file that was already 
opened on another channel, but the path to the file was different. For example: 


The OPEN(2) will fail with an !ERROR=0. This has been corrected in Revision 1.04 through the use of a new SETOPTS bit. 

The new bit is Byte 7 Bit 1. When this bit is set, Visual PRO/5 behaves in the same manner as the PRO/5 UNIX ports. For 


share the same FCB which prevents an extra user slot being taken on the file and the !ERROR=0 for single user product. The FID() information is that of channel 1 in this case. The file name reported at offset 9 in FID(2) is exactly the same as that of FID(1) (i.e., “file”). Had channel 2 been open first the file name info in the FID(1) would be “./file”. 

As a result of this correction, multiple channels to the same opened file use a single FCB. 

* The FIN() function now correctly returns the number of available columns for a SYSPRINT channel at Byte 7. In previous versions, the number of compressed print columns was being reported after an open of a SYSPRINT device even though the device wasn’t in compress print mode. 

* During installation, if the install is to a Windows ’95 or Windows NT system, WIN32 console mode versions of pro5cpl.exe and pro5lst.exe are installed. On WIN32s (i.e., Windows 3.1 and Windows 3.11) a DOS386 version of these tokenizers is installed. 

* Several problems introduced in Visual PRO/5 1.01 have been fixed by using the latest version of XVT. Four new DLLs are now required. The problems had to do with PRINT not working from the SYSWINDOW menu and ‘PWINDOW’ not printing correctly. 

* A GPF would occur in some instances of using TEXTEDIT controls. This latest release of XVT DLLs solves this problem. 

* Visual PRO/5 is now built with Microsoft’s Visual C++ Version 4.1 and requires MSVCRT40.DLL in addition to the older MSVCRT20.DLL. 

* Changing the font on EDIT controls is now working correctly under 1.04. In 1.01, EDIT control font changes would change the font, but would cause alignment to be incorrect. 

* The line spacing which is computed after software issues a ‘FONT’ mnemonic was not remembered past the first page. After selecting a font, Visual PRO/5 software computes the line spacing for subsequent lines but was reverting back to the initially computed line spacing after the page where the ‘FONT’ mnemonic was encountered. Visual PRO/5 now remembers the line spacing correctly between pages. 

* Previously, Visual PRO/5 did not set the initial page position to zero at the start of a print job. Subsequent pages began at the Windows print driver’s line zero, but the first page may or may not have begun on the correct line. This has been fixed. 

* Previously, initial line feeds in Visual PRO/5 software were ignored. When a print job began with initial line feeds 
(i.e., generally for alignment), Visual PRO/5 tossed them out when it first encountered real data. Initial line feeds are no 
longer ignored. 

* Many heap problems that were occurring in Visual PRO/5 have now been corrected. Visual PRO/5 is now built with a performance enhanced heap manager which is more reliable. 

* A problem in Visual PRO/5 printing in Revision 1.01 that resulted in an !ERROR=0 [TCB(10) = -1121] has been fixed. 
In some cases on Windows ’95 the operating system reports LPTn: devices as being serial devices. During output to the device it eventually determines that it is a parallel device. There is a fixed lpt.vxd driver on Microsoft’s ftp site (ftp.microsoft.com) that fixes most of the problem seen by customers printing to LPTn: devices. 

* On Windows ’95 and Windows 3.1 systems that have heavy disk I/O, Visual PRO/5 applications were failing in various ways ranging from heap errors to incorrect FID information. This occurs because Windows ’95 and Windows 3.1 systems will fail to open files which is normal during a prefix search; however Windows fails to also report why it fails. Visual PRO/5 now recognizes this situation correctly and will attempt to determine if the file exists in another way. If 
after three retries without determining the cause of the failure, an !ERROR=60 will be reported. To date our field testing has been unable to reproduce an !ERROR=60 after retrying even under the heaviest system loading. 

* A GPF occurred when ‘DESTROY’ with a non-existent context greater than 1 was specified. This no longer occurs. 

* A SYSWINDOW that is invisible on exit no longer becomes visible when Visual PRO/5 exits. 

* When starting Visual PRO/5 with the -q option (quiet), Visual PRO/5 no longer displays its splash screen which was interfering with customer splash screens. 

* A GPF could occasionally occur when a ‘WINDOW’ was created in a SYSWINDOW and scrolling was turned off. If the application used the ‘CE’ mnemonic, Visual PRO/5 would GPF if the current location in the ‘WINDOW’ was below the actual screen. 

Changes from Revision 1.01 to Revision 1.03: 

* When opening and closing many resource files there was a potential for not freeing resources after each close. The problem has been corrected. 

* Custom Edit controls now offer improved scrollbar handling. 

* When navigating through grouped radio buttons, the arrow keys now function correctly. 

* Revision 1.03 corrected a problem where a docked window would not be initially cleared to the background color correctly. 

* Using OPTION=NOTITLE in the Resource Editor no longer causes Visual PRO/5 to issue a protection fault. 

* In Visual PRO/5, menu items created with defined hot keys have the potential of being erroneously displayed with misplaced hot keys. The hot keys defined are still functional even though they may not appear to be (i.e., no underscore under the appropriate letter). Related to this problem is the potential for hot keys to appear on menu items that define no hot keys, and they may indeed be functional as well. In some cases, these extraneous hot keys may even appear on a defined accelerator key label. 

* A problem involving the unnecessary redrawing of layered drawing objects (such as ellipses and rectangles) when another window is placed over and subsequently removed from the drawing surface has been fixed whenever a rectangle is the topmost object, but only when drawing units are set to ‘pixels’ (DEFAULT). If the drawing units are set to ‘1000ths of an inch,’ then the redraw problem will still occur, as it will for any other type of drawing object. 

* When printing directly to a COM or LPT port, the TIM= option may not work correctly. 

* Custom Edit controls should not contain more than 65535 lines of text as odd wrapping behavior will occur if you attempt 
to load a Custom Edit control with more than 65535 lines. In addition, paragraphs numbered past this limit are not accessible from Visual PRO/5. 

Changes from Revision 1.0 to Revision 1.01: 

* A new window creation flag has been added for windows with no title bar. The flag’s value is $01000000$. Windows with no title bar can also be created via the resource editor by adding an option string with the text “TITLE=NONE”. 

* A new window creation flag has been added to permit the Enter key to act like the Tab key (advance to next field) with respect to dialog navigation. The flag’s value is $00800000$. This feature may also be enabled via the resource editor by adding an option string with the text “ENTER=TAB”. 

* It is now possible to associate a hotkey with any SYSGUI window or control that can receive keyboard focus (user input). For example, listboxes and edit controls can now have hotkeys. The way to do this is to place a static text control next to the control in question, and assign the hot key to that static text control. The static text control must have an ID that is lower than the ID of the associated control, but no lower than any other control in the same context. When the hotkey is detected, Visual PRO/5 locates the associated control or window. If that control or window can receive keyboard 
focus (i.e., it is not disabled or invisible), it will. This enhancement is intended primarily for new development. For existing 
resources, it might be impractical to renumber the controls. In a future release of Visual PRO/5, non-sequential numbering will be compatible with this feature. 

* If the title of a SYSGUI control is changed with the ‘TITLE’ mnemonic, it is now possible to change the hotkey associated with the control at that time. Simply use the usual syntax with the ampersand (&) character immediately preceding the hotkey character. 

* Visual PRO/5 ships with Microsoft’s WIN32s package, which is required to use Visual PRO/5 (a 32-bit executable) under Windows 3.1x and Windows For Workgroups. WIN32s is not required (and is not installed) with Windows 95 or Windows NT. If you already have WIN32s installed on your machine, you may elect not to install the copy BASIS provides. The version of WIN32s that currently ships with Visual PRO/5 is 1.25. BASIS has not tested Visual PRO/5 with older or newer versions of WIN32s. 

* Under Windows and Windows for Workgroups 3.1x, the COM and LPT ports do not respond correctly to timeouts. This is not a problem under Windows 95 or Windows NT. BASIS will attempt to obtain fixes to the WIN32s drivers from Microsoft, or devise a workaround. There are no fixes or workarounds available at this time. 

* Where a Novell network has an LPT port captured, Visual PRO/5 might not be able to print to it, this depends on the operating system and drivers in use. 

* If a SYSGUI window is allowed to report resize events (via the event mask), many extra (intermediate) resize events may be reported on platforms such as Windows 95 and Windows NT. On these platforms, it is normal for applications to dynamically respond to resizing, instead of simply drawing the window frame and waiting for the mouse button to be released, as with Windows and Windows for Workgroups. 

* The “Run Minimized” property in Windows will work with Visual PRO/5. 

* Whenever a SYSWINDOW requires input, it is automatically made visible, raised, enabled, unminimized, and focused. Because of this, the “Run Minimized” property and the INVISIBLE and MINIMIZED modes may not appear to work as expected. These features work only when no input is required from the SYSWINDOW console. If you start a program from the command line that does not use input from the console window, then the “Run Minimized” property and the INVISIBLE and MINIMIZED modes will function as expected. 

* If the ‘IMAGE’ mnemonic is used to plot graphical images, avoid using the “grab palette” feature for applications that must run on Windows or Windows for Workgroups. These environments can become confused and hang if palettes are switched too frequently. This is not a problem with Windows 95 or Windows NT. 

* Under REV 1.0, all SYSGUI windows automatically received a custom “color cube” palette, for more accurate display of colors in bitmapped images. This has proved to be problematic for two reasons: 

(1) Microsoft’s WIN32s (Windows and Windows for Workgroups) can crash if focus is shifted between windows repeatedly, forcing many swift palette changes. 

(2) Colors in controls, which are always rendered in the stock system palette, often did not match exactly the colors in the window. 

For example, an attempt to create a light gray “3d-look” dialog box would lead to unsightly mismatched colors on some systems. As a result, the custom “color cube” palette is now optional, and by default is not used. In REV 1.01, SYSGUI windows normally inherit the stock system palette. If you display photographic bitmaps and would like to use the custom “color cube” palette as before for better color accuracy, use the new window creation flag $00400000$. 

* Whenever a SYSGUI window with a custom palette gains focus, and the display has 256 colors or fewer, you may notice some color “flashing” as focus shifts between windows. This is normal and you may see this behavior with other applications that require accurate color displays. If you find the flashing objectionable, the best way to avoid this is to use a display mode that permits more than 256 colors (usually 65,536 colors or 16M colors). Sometimes using simpler wallpaper or not using a wallpaper background can help. 

* Though the ‘CUE’ mnemonic is a very useful interface enhancer, it can have some undesirable side effects: 

(1) It increases CPU usage whenever the mouse pointer is inside a window with cues. It also disables the ability to switch tasks with <Alt>+<Tab> under Windows and Windows for Workgroups (this is not a problem under Windows 95 and Windows NT). 

(2) Certain controls may operate erratically if they are inside a window with cues enabled. (In particular, any control or child window with scroll bars should be kept out of windows with cues.) By restricting the use of cues to child windows filled with tool buttons (tool bars), these negative effects are kept to a minimum, since the mouse is seldom kept hovering over a tool bar for long periods of time. 

It is recommend that you use cues in tool bars freely (this is the most common use for cues), and use them elsewhere at your own risk. However, some BASIS demo programs break this rule. 

* The ‘CUE’ mnemonic will reliably work only if there are a few pixels’ clearance on all sides of the cued object. This is because ‘CUE’ relies on monitoring the movement of the mouse pointer on to and off of the cued object. 

* A problem with cues was fixed in REV 1.01. It was if the mouse was moved too quickly, some cues would not activate. 

* If an object with an associated cue is very close to the edge of the screen, it is possible for the cue to appear partially off-screen. This problem will be fixed. 

* If opaque, scaled text (‘OPAQUE'(2), the default setting) is plotted to a SYSGUI window using ‘PLOTTEXT’, and then subsequently printed to a high-resolution printer, the text may appear grainy. This will be addressed in a future revision. For now, to obtain the best print quality, BASIS recommends using non-scaled text (option 1) for SYSGUI printing of plotted text. 

* If “transparent text” is drawn using the ‘PLOTTEXT’ mnemonic on the SYSGUI device, it always plots in COPY mode. In particular, the XOR drawing mode will not work with transparent text. 

* Your graphical resources will look best on a wide variety of displays if you use ‘SEMICHARS’ as the unit of measure instead of the default ‘PIXELS’. See your PRO/5 documentation for more details. 

* Visual PRO/5 REV 1.01 now sets the default background color in all windows and dialogs (other than the terminal window) to the current “dialog” background color as selected by the user’s color scheme. This was necessary to accommodate the new Windows 95 interface and color scheme, which was introduced subsequent to the release of 
Visual PRO/5 REV 1.0. Existing applications may need to explicitly set the background color (e.g., ‘CLEAR'(“WHITE”)) of any windows which should not receive the new background color. The default was changed, because on newer Windows platforms, any SYSGUI window that has controls in it is likely to look “wrong” without the new default color setting. A side effect of this change is that SYSGUI windows with menubars will show no distinct break between the bottom 
of the menubar and the top of the client area (i.e., they are adjacent and the same color). It is possible to remedy this at the workstation level by editing the system color scheme and changing the menubar color. It is also possible to remedy this at the application level by clearing the window to a new background color. However, this solution is only acceptable if there are never any controls in the window. Since Visual PRO/5 permits tremendous flexibility, even permitting controls 
to be added to windows on-the-fly, BASIS could not safely make any assumptions about when to use a different background color. For a future release, we are exploring ways to eliminate this complication and automate this process for developers. 

* REV 1.01 observes the color schemes of Windows 3.1x, Windows for Workgroups 3.1x, Windows NT, and Windows 95. 

* While Visual PRO/5 offers the ability to change the colors and fonts used in nearly every type of graphical object, the behavior of colors and fonts may vary widely from one platform to the next, and even (due to changes in third-party libraries BASIS depends on) from one release of Visual PRO/5 to the next. Every attempt has been made to provide consistent behavior, but the variation in monitors, graphics drivers, installed fonts, and etc., makes it impossible for many guarantees. For best results on all platforms, BASIS recommends that you use contrasting colors (use the defaults where acceptable), and avoid using exotic RGB values. It is also recommend that you use the five “standard” font names as described in the documentation for the ‘FONT’ mnemonic, and avoid using nonportable fonts. (Use the default font where acceptable.) 

* If a full window custom edit control is created with the Wrap attribute set, the control will reset to the top any time the window is resized. This is due to the recomputation of the wrap margins. If the Wrap attribute is not set, the control will not reset when the window is resized.

* Vertical scroll bars in custom edit controls can now move to the bottom of the page. 

* SYSGUI keyboard focus is intended to act as a hierarchy, which it does for the most part. As focus shifts from a window to controls inside that window, the parent window is still considered to have focus. However, there are exceptions. Currently whenever a child window, custom edit control, or tool button gains focus, a focus loss event is reported (if permitted by the event mask) in the parent window. This is expected to change in a future release. 

* Some focus change events were reported inconsistently. This has been fixed. Now if focus is currently on an edit control, and a button is operated, the sequence of events is the same regardless of whether the mouse or the keyboard caused the button to operate. 

* Ordinarily, any time a list edit or edit control loses focus, an “f” event is reported (if permitted by the event mask). BASIS is aware of a bug, however, where a focus loss on a list edit or edit control is not reported, if the object gaining focus is a custom edit control. This will be fixed in a future release. 

* If keyboard navigation is enabled, tabbing to a group of radio buttons causes the first button in the group to be checked. It should receive keyboard focus, but should not be checked. This will be fixed in a future release. 

* Keyboard navigation in child windows is permitted in REV 1.01. 

* If no default printer has been assigned and a print operation is attempted, sometimes not one, but two error dialogs are generated. This will be fixed in a future release. 

* Certain characters whose codes are greater than 127 cannot be entered correctly. Additionally, there is no keyboard sequence which will successfully enter the NUL (ASCII 0) character. This is still under investigation. 

* As of REV 1.01, I/O redirection (use of ‘>’ and ‘<‘ on command line) is now working on all platforms. Under Windows and Windows for Workgroups, it is necessary to supply redirection commands the same way other PRO/5 command line options are supplied. This is with no embedded spaces, and before any “-” by itself. For example: 

        COMMAND STRING                           NT         W95         Win/WFW 
        vpro5 <in.txt >out.txt                  OK         OK         OK 
        vpro5 – <in.txt >out.txt         OK         OK         no 
        vpro5 < in.txt > out.txt         OK         OK         no 

The reason is that Windows 95 and Windows NT parse the command line (outside the control of PRO/5), whereas Windows and Windows for Workgroups require the application to do it. 

With Visual PRO/5, I/O redirection is an all-or-nothing proposition. FID(0) cannot be set to “IO” unless a redirection has been supplied for both input and output. If input is redirected, output must also be redirected and vice-versa. 

If you try to use I/O redirection with Windows 3.1x using a DOS prompt window, you will see the message stating, “This program cannot be run in DOS mode.” Instead, you must use the Windows RUN command. 

* ‘FLUSH’ now clears all pending events, not just all events that have already been processed by PRO/5. 

* A problem with checkable menu items in SYSGUI windows has been fixed. 

* The ‘w’ type events (i.e., scroll tracking) were reported even though they are not documented. These events have been removed until they work correctly. 

* Visual PRO/5 allocates a 100 byte communications buffer for each channel opened to a serial port. 

* The CTRL() function cannot return more than 4K of data. This is of particular importance when function 7 (“get all text”) is used on a custom edit control. For controls with more than 4K of data, it is necessary to use function 5 (“get custom edit paragraph by number”) for each paragraph in the control. Function 3 (“get count”) returns the total number of paragraphs. 

* A device read timeout was artificially prolonged, making the machine appear that it was not responding. This has been fixed in REV 1.01. 

* The introductory window (“splash screen”) now displays only for the first Visual PRO/5 task to start. As long as there is a Visual PRO/5 task currently running on the machine, additional tasks may be started without the introductory window appearing. 

* The Multi-Workstation version of Visual PRO/5 is no longer specific to the Microsoft Windows for Workgroups network (and no longer relies on NETDDE) in REV 1.01. This makes the product more portable and less vulnerable to NETDDE failures. 

* Abortive access to the SYSPRINT device sometimes caused opened files to be closed in REV 1.0. This was fixed in REV 1.01. 

* If a nonexistent font name is specified in the PRO5.INI file, Visual PRO/5 will always select an available fixed-pitch font, which will be locatable in the fonts/size dialog. This fixes the problem in REV 1.0 where a nonexistent font in the .INI file could cause the Fonts/Size dialog to appear in an indeterminate state. 

* F1 may now be used as a menu accelerator without interfering with the menu’s display of the item’s mnemonic. 

* A bug in the SYSGUI ‘POP’ operation which was causing GPFs has been fixed. 

* Overlapping objects drawn in a SYSGUI window now cancel each other out (i.e., in all cases) as documented. 

* Windows 95 has the ability to scale “unscalable” fonts, which confused REV 1.0 when an unscalable font and the “vary font size” option were selected. REV 1.01 now expects this behavior and works around it. 

* Visual PRO/5 REV 1.01 no longer stops responding if started with a config.bbx file with no SYSWINDOW alias lines in it. 

* The ‘TXAPPEND’ SYSGUI mnemonic no longer causes a GPF when passed a nonexistent paragraph number. 

7. Resource Editor RELEASE NOTES 

Changes from Revision 1.01 to Revision 1.04: 

* Two new entries in the pro5.ini file have been added. 

minctlheight controls the minimum height in pixels that is allowed for controls. 

minctlwidth controls the minimum width in pixels that is allowed for controls. 

These values default to 10, and should not be set below 4. 

* Resedit handles very long (greater than 128 characters) titles for controls without a GPF. 

* If the OPTION strings window is hidden behind other windows, pressing the “Option strings” button on the attributes window raises the window to the top of the stack. 

Changes from Revision 1.0a to Revision 1.01: 

* Changes to a resource that involve only an option string change can now be saved. The user will also be given the option to save changes when exiting. 

* Changing the units on windows that contain small controls (approximently 10×10 pixels) will no longer cause erroneous error dialogs to be displayed when the control’s properties are modified. 

* When the units are changed in the Window Attributes dialog, the Windows Attributes dialog no longer loses focus. 

8. Novell NetWare 
The Visual PRO/5 Novell NetWare Client version includes several special areas where you need to be aware of the situation. 

* Novell NetWare Client32 version 2.12 or higher is required to insure proper shutdown procedures in both the PRO/5 client and the Data Server NLM. When the Ctrl+Alt+Delete command is used, versions 2.11 or earlier of Client32 do not properly shut down the client connection, leaving the client and server in an unstable condition. This instability can cause the PRO/5 client to hang and produce an unstable Data Server NLM. 

* The INFO() function has several items that are different. 

INFO(2,…) does not return the user slot information because no user slot license checking is performed. 

(Items labeled as “NDS and Bindery” are obtained from NetWare Directory Services if the connection supports it. If NDS is not available, the items are read from the bindery or emulated bindery before a failure is reported.) 

INFO(3,2) returns the user name (NDS and Bindery. 
INFO(3,3) returns the user description (NDS and Bindery). 

* If you are using NDS to access a remote spooled printer, it may be necessary to specify the server= mode option if an !ERROR=60 occurs with TCB(10) equal to -35228. 

* For more information on enhancements specific to the Visual PRO/5 Novell Client see the online Help version of the Installation and Configuration Guide in PRO/5 Under Novell NetWare section. 


A new utility _dtom has been added to the utility set to help in converting DIRECT files to single keyed MKEYED files. This utility will help sites with extremely large DIRECT files that are limited in disk space for doing the conversion. 


* On SCO XENIX machines, using the float and/or double float data types in templates will cause a floating point exception error (core dump). This is a known problem with SCO XENIX and SCO has not been able to provide a solution to BASIS. 

* In Visual PRO/5 if unexpected !ERROR=46 or !ERROR=1 occur on the READ of a SELECT channel, you must empty your temp directory. 

* Installing Visual PRO/5 to a Windows 95 mapped drive over a network from a Windows 95 workstation does not activate correctly. 

Installing Visual PRO/5 to a mapped Windows 95 network drive from a Windows NT workstation or from Windows for Workgroups 3.11 works correctly. 

Installation from a Windows for Workgroups 3.11 machine returns a notice of a sharing violation after activating. However, in most instances there is no sharing violation and the installation and activation are completed as expected. The cause of this problem is not known at this time. 

* Visual PRO/5 Rev 1.05 can handle encounters with corrupted files but may behave differently depending on the installed system. 

On Windows for Workgroups 3.11 and Windows NT 4.0 Visual PRO/5 will report an !ERROR=2 if it encounters a file where the key pointers are pointing to invalid records within the file. 

On Windows 95 no error is reported and the read continues. This problem is being looked at now. Note that this does NOT mean that Visual PRO/5 is corrupting files. 

* Using SQLTMPL or SQLFETCH with SQL aggregate functions COUNT, SUM, MIN, MAX, & AVG on PRO/5 UNIX platforms with Visigenic ODBC may produce errors. You must create a column alias using AS in the 
SELECT statement for aggregate functions to return correct results. 

For example. 

SELECT AVG(ship_weight) AS avg_wt FROM orders 

This is not a problem when using aggregate functions in the native BASIS SQL engine. 

* SQLOPEN on PRO/5 UNIX platforms with BASIS-supplied Visigenic ODBC drivers – AIX, HP/UX, Solaris, SCO UNIX – will create processes that do not terminate until PRO/5 exits. This may consume all available processes during long PRO/5 sessions. Exiting PRO/5 restores the available memory. 

* Using the Microsoft DBASE III driver version dated 3/26/97 from the ODBC Desktop Driver Pack 3.0 may cause Visual PRO/5 to crash while importing data. Previous versions of the MS DBASE III driver do not cause this problem. 

* Creating a file on a mapped MS Windows network drive when the drive’s disk is full (!ERROR=12) will cause the PRO/5 DOS 386 single-user version to terminate abnormally on subsequent END or CLOSE statements. 

[end of file] 

Last Modified: 01/28/1998 Product: PRO/5 Operating System: N/A

BASIS structures five components of their technology into the BBx Generations.

Table of Contents
Scroll to Top