ordBagExt
ordBagName
ordCondSet
ordCreate
ordDestroy
ordFor
ordKey
Tag Archives: OUTERR()
Harbour Terminal Functions
HB_EOL()
HB_EOL()
Returns the newline character(s) to use with the current OS
Syntax
hb_eol() --> cString
Returns
<cString> A character string containing the character or characters required to move the screen cursor or print head to the start of a new line.
Description
Returns a character string containing the character or characters required to move the screen cursor or print head to the start of a new line for the operating system that the program is running on (or thinks it is running on, if an OS emulator is being used).
Under HB_OS_UNIX operating system the return value is the Line-Feed character (0x0a, CHR(10)); with other operating systems (like DOS) the return value is the Carriage-Return plus Line-Feed characters (0x0d 0x0a, CHR(13)+CHR(10)).
Examples
// Get the newline character(s) for the current OS. // Get the newline character(s) for the current OS. STATIC s_cNewLine ... s_cNewLine := hb_eol() ... OutStd( "Hello World!" + s_cNewLine )
Tests
? ValType( hb_eol() ) == "C" ? Len( hb_eol() ) == 1
Compliance
Harbour
Platforms
All
Files
Library is rtl
Seealso
OS(), OUTSTD(), OUTERR()
C5DG-9 Terminal Drivers
Clipper 5.x – Drivers Guide
Chapter 9
Alternate Terminal Drivers
Clipper supports a driver architecture that allows Clipper- compiled applications to use alternate terminal drivers. This architecture provides support for nonstandard video hardware and ANSI output devices, allowing your applications to run in a wider variety of environments.
The following terminal drivers are supplied as part of the Clipper Development System and are discussed in this chapter:
. The ANSITERM driver provides ANSI terminal support for systems that require it
. The NOVTERM driver causes Clipper applications to execute faster when run on some nondedicated network server software
. The PCBIOS driver provides direct BIOS calls rather than direct screen writes for systems requiring this form of I/O
In This Chapter
This chapter discusses how Alternate Terminal Drivers fit into the overall Clipper architecture as well as how to install and use each of the supplied terminal drivers. The following major topics are discussed:
. The Alternate Terminal Driver Architecture
. The ANSITERM Alternate Terminal Driver
. The NOVTERM Alternate Terminal Driver
. The PCBIOS Alternate Terminal Driver
The Alternate Terminal Driver Architecture
In Clipper, communication with I/O devices is controlled by a multilayered terminal system. At the lowest level is the terminal driver which controls screen and keyboard activity. It consists of a screen and keyboard driver that communicates directly with the I/O device (operating system or hardware). It is the device specific part of the Clipper terminal system.
There is, then, a higher level system that communicates with terminal drivers. This system is known as the General Terminal (GT) system and provides general services that create Clipper screen and keyboard commands and functions. The following figure demonstrates:
+—————————————–+
| CA-Clipper screen and keyboard commands | | and functions | |-----------------------------------------| | General Terminal (GT.OBJ) | ------------------------------------------| | Terminal Driver | |-----------------------------------------| | Screen | Keyboard | +-----------------------------------------+
The default terminal driver, designed for IBM PC and 100% compatibles, is supplied as a library file (TERMINAL.LIB) installed into your \CLIPPER5\LIB directory. This driver links into each program automatically if you specify no alternative terminal driver provided that you do not use the /R option when you compile. An alternate terminal driver is supplied as a separate library (.LIB) file that links into an application program in place of the default terminal driver if you specify it on the link line.
All alternate terminal drivers work through the General Terminal layer as supplied in the file GT.OBJ. The Clipper installation program installs this file in the \CLIPPER5\OBJ subdirectory on the drive that you specify, so you need not install the driver manually.
The ANSITERM Alternate Terminal Driver
The ANSITERM terminal driver supports the ANSI screen mode for all screen display from Clipper programs.
This screen mode is installed by specifying ANSI.SYS in the user’s CONFIG.SYS. ANSI.SYS replaces the default DOS CON device driver for video display and keyboard input. Once installed it supports ANSI escape sequences to erase the screen, set the screen mode, and control the cursor in a hardware-independent way. Most modern DOS programs, however, do not use it and write either directly to the video hardware or use BIOS routines for enhanced screen performance.
Use the ANSI screen mode for Clipper programs that run on hardware that does not support either writing to video hardware or BIOS calls for screen display. This is the case when using alternative display hardware to support the blind.
Note: The ANSITERM terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.
Installing ANSITERM Terminal Files
The ANSITERM terminal driver is supplied as the file ANSITERM.LIB. The Clipper installation program installs this file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.
Linking the ANSITERM Terminal Driver
To link the ANSITERM alternate terminal driver into an application program, you must specify both GT.OBJ and ANSITERM.LIB to the linker along with your application object (.OBJ) modules.
1. To link with .RTLink using positional syntax:
C>RTLINK <appObjectList> GT,,, ANSITERM
2. To link with .RTLink using freeformat syntax:
C>RTLINK FI <appObjectList>, GT LIB ANSITERM
3. To link with .RTLink using ANSITERM.PLL and freeformat syntax:
C>RTLINK FI <appObjectList> /PLL:ANSITERM
Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.
Important! You cannot link the ANSITERM driver with BASE52.PLL. An application linked with both ANSITERM.LIB and BASE52.PLL may cause the computer to freeze upon execution.
The Runtime Environment
Using ANSITERM.LIB requires that ANSI.SYS be installed on the user’s computer. To accomplish this, include the following statement in the user’s CONFIG.SYS:
DEVICE=ANSI.SYS
Performance Concerns
Because the ANSITERM terminal driver uses buffered screen writes for all screen painting, some operations, especially those that scroll the screen, are slow. These include:
1. All box drawing commands and functions
2. All console commands and functions when scrolling
3. All clear screen commands and functions
4. All restore screen commands and functions
5. Standard out functions (OUTSTD() and OUTERR()) whether the screen is scrolling or not
Note: Overall performance of Clipper programs is slower since the ANSITERM terminal driver must spend more time polling for user events than the standard Clipper terminal driver.
Screen Output from C and Assembly Language
The ANSITERM terminal driver overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. As a consequence, you should perform all screen output from Clipper.
The ANSITERM terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor will not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions instead.
Other Incompatibilities
1. ISCOLOR() always returns false (.F.).
2. When you load DBU, the default color mode is monochrome unless you specify DBU with the /C command line option.
3. The first time you invoke the Debugger, the default color mode is also monochrome unless you set the Options:Mono display off.
4. When an application linked with the ANSITERM terminal driver terminates, the last color set in the application becomes the DOS color. This happens since colors set with ANSITERM are global to DOS and Clipper cannot query DOS for the current screen colors as the application loads.
5. Nondisplaying ASCII characters are presented as a space by the ANSITERM terminal driver. These include BELL (CHR(7)), BS (CHR(8)), TAB (CHR(9)), LF (CHR(10)), CR (CHR(13)), and ESC (CHR(27)).
The NOVTERM Alternate Terminal Driver
The NOVTERM terminal driver is a special-purpose driver that circumvents an incompatibility between some nondedicated network server software and Clipper. This incompatibility causes printers connected to the server to slow to an unusable rate.
Clipper applications and nondedicated servers compete for resources. Clipper applications make use of the time between keystrokes to perform various system tasks. This greatly improves the application’s overall performance by limiting its idle time. Certain nondedicated servers only attempt to print within an application’s idle time. Since a Clipper application is seldom idle, this greatly slows printing.
Important! The NOVTERM terminal driver corrects the incompatibility by preventing the Clipper application from using idle time. Because this can severely hamper performance, you should only use the NOVTERM terminal driver when necessary, and then you should link it only into those applications that are physically running the nondedicated server.
Note: The NOVTERM terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.
Installing NOVTERM Terminal Files
The NOVTERM terminal driver is supplied as the file NOVTERM.LIB. The Clipper installation program installs the driver file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.
Linking the NOVTERM Terminal Driver
To link the NOVTERM alternate terminal driver into an application, you must specify both GT.OBJ and NOVTERM.LIB to the linker with your application object (.OBJ) modules.
1. To link with .RTLink using positional syntax:
C>RTLINK <appObjectList> GT,,, NOVTERM
2. To link with .RTLink using freeformat syntax:
C>RTLINK FI <appObjectList>, GT LIB NOVTERM
3. To link with .RTLink using NOVTERM.PLL and freeformat syntax:
C>RTLINK FI <appObjectList> /PLL:NOVTERM
Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.
Important! You cannot link the NOVTERM driver with BASE52.PLL. An application linked with both NOVTERM.LIB and BASE52.PLL may cause the computer to freeze upon execution.
Performance Concerns
Overall performance of Clipper programs is slower since the NOVTERM terminal driver must spend more time polling for user events than the standard Clipper terminal driver and since the program will not use its idle time for other tasks.
Screen Output from C and Assembly Language
The NOVTERM terminal driver overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. Therefore, you should perform all screen output from Clipper.
The NOVTERM terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor will not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions.
The PCBIOS Alternate Terminal Driver
The PCBIOS terminal driver uses BIOS calls instead of direct screen writes. It is designedd for applications that trap BIOS calls to redirect output over telecommunication lines or to convert output to a form compatible with two-byte character sets.
Note: The PCBIOS terminal driver fully supports all screen and keyboard functionality of the default terminal driver. This includes the ability to save and restore screens and support for all keys on the standard 101-key keyboard.
Installing PCBIOS Terminal Files
The PCBIOS terminal driver is supplied as the file, PCBIOS.LIB. The Clipper installation program installs the driver file in the \CLIPPER5\LIB subdirectory on the drive that you specify, so you need not install it manually.
Linking the PCBIOS Terminal Driver
To link the PCBIOS alternate terminal driver into an application program, you must specify both GT.OBJ and PCBIOS.LIB to the linker in addition to your application object (.OBJ) modules.
1. To link with .RTLink using positional syntax:
C>RTLINK <appObjectList> GT,,, PCBIOS;
2. To link with .RTLink using freeformat syntax:
C>RTLINK FI <appObjectList>, GT LIB PCBIOS
3. To link with .RTLink using PCBIOS.PLL and freeformat syntax:
C>RTLINK FI <appObjectList> /PLL:PCBIOS
Note: These link commands assume you have set the LIB, OBJ, and PLL environment variables to the standard locations. They also assume that the Clipper programs were compiled without the /R option.
Important! You cannot link the PCBIOS driver with BASE52.PLL. An application linked with both PCBIOS.LIB and BASE52.PLL may cause the user’s computer to freeze when the user executes it.
Performance Concerns
Because the PCBIOS terminal driver uses buffered screen writes for all screen painting, some operations, especially those that scroll the screen, are slow. These include:
1. All box drawing commands and functions
2. All console commands and functions when scrolling
3. All clear screen commands and functions
4. All restore screen commands and functions
5. Standard out functions (OUTSTD() and OUTERR()) whether the screen is scrolling or not
Screen Output from C and Assembly Language
The PCBIOS terminal driver also overwrites all output from C and Assembly Language when it refreshes the screen from the screen buffer. Therefore, you should perform all screen output from Clipper.
The PCBIOS terminal driver also virtualizes the cursor. This means that BIOS functions that report the location of the hardware cursor do not always return the correct value. To obtain the cursor position, use Clipper’s ROW() and COL() functions.
Summary
This chapter has introduced you to the Alternate Terminal Driver concept, giving you specific information on the architecture used to implement them in Clipper. Each of the alternate terminal drivers supplied with Clipper was discussed, including how to link and use it into your application and the implications of doing so.
C5_OUTERR
OUTERR() Write a list of values to the standard error device ------------------------------------------------------------------------------ Syntax OUTERR(<exp list>) --> NIL Arguments <exp list> is a list of values to display and can consist of any combination of data types including memo. Returns OUTERR() always returns NIL. Description OUTERR() is identical to OUTSTD() except that it writes to the standard error device rather than the standard output device. Output sent to the standard error device bypasses the Clipper console and output devices as well as any DOS redirection. It is typically used to log error messages in a manner that will not interfere with the standard screen or printer output. Examples . This example displays an error message along with the date and time of occurrence to the screen: OUTERR("File lock failure", DATE(), TIME()) Files Library is CLIPPER.LIB.
See Also: OUTSTD()
C5 Error Handling
C5 Error Handling Commands, Statements and Funtions
Statement :
BEGIN SEQUENCE :
Define a sequence of statements for a BREAK
BEGIN SEQUENCE <statements>... [BREAK [<exp>]] <statements>... [RECOVER [USING <idVar>]] <statements>... END [SEQUENCE]
Functions :
ALTD() :
Invoke the Clipper Debugger
ALTD( [ <nAction> ] ) --> NIL
BREAK() :
Branch out of a BEGIN SEQUENCE…END construct
BREAK( <exp> ) --> NIL
DOSERROR() :
Return the DOS error number
DOSERROR( [ <nNewOsCode> ] ) --> nOsCode
ERRORBLOCK() :
Post a code block to execute when a runtime error occurs
ERRORBLOCK( [ <bErrorHandler> ] ) --> bCurrentErrorHandler
ERRORLEVEL() :
Set the Clipper return code
ERRORLEVEL( [ <nNewReturnCode> ] ) --> nCurrentReturnCode
NETERR() :
Determine if a network command has failed
NETERR( [ <lNewError> ] ) --> lError
OUTERR() :
Write a list of values to the standard error device
OUTERR( <exp list> ) --> NIL
PROCLINE() :
Return the source line number of the current or previous activation
PROCLINE( [ <nActivation> ] ) --> nSourceLine
PROCNAME() :
Return the name of the current or previous procedure or user-defined function
PROCNAME( [ <nActivation> ] ) --> cProcedureName
Error Class :
Provides objects containing information about runtime errors.
Description :
An Error object is a simple object that contains information pertaining to a runtime error. Error objects have no methods, only exported instance variables. When a runtime error occurs, CA-Clipper creates a new Error object and passes it as an argument to the error handler block specified with the ERRORBLOCK() function. Within the error handler, the Error object can then be queried to determine the nature of the error condition.
Error objects can also be returned to the RECOVER statement of a BEGIN SEQUENCE construct with a BREAK statement. Here, the error object can be queried for local error handling. For more detailed information and examples refer to the Error Handling Strategies chapter in the Programming and Utilities guide.
Class Function :
ErrorNew() :
Returns a new Error object.
ErrorNew() --> objError
Exported Instance Variables :
args (Assignable) :
An array of function or operator arguments.
Contains an array of the arguments supplied to an operator or function when an argument error occurs. For other types of errors, Error:args contains a NIL value.
canDefault (Assignable) :
Indicates whether or not default recovery is available.
Contains a logical value indicating whether the subsystem can perform default error recovery for the error condition. A value of true (.T.) indicates that default recovery is available. Availability of default handling and the actual default recovery strategy depends on the subsystem and the error condition. The minimum action is simply to ignore the error condition.
Default recovery is requested by returning false (.F.) from the error block invoked to handle the error. Note that Error:canDefault is never true (.T.) if Error:canSubstitute is true (.T.).
canRetry (Assignable) :
Indicates whether or not a retry is possible after an error.
Contains a logical value indicating whether the subsystem can retry the operation that caused the error condition. A value of true (.T.) indicates that a retry is possible. Retry may or may not be available, depending on the subsystem and the error condition.
Retry is requested by returning true (.T.) from the error block invoked to handle the error. Note that Error:canRetry never contains true (.T.) if Error:canSubstitute contains true (.T.).
canSubstitute (Assignable) :
Indicates if a new result can be substituted after an error
Contains a logical value indicating whether a new result can be substituted for the operation that produced the error condition. Argument errors and certain other simple errors allow the error handler to substitute a new result value for the failed operation. A value of true (.T.) means that substitution is possible.
The substitution is performed by returning the new result value from the code block invoked to handle the error. Note that Error:canSubstitute is never true (.T.) if either Error:canDefault or Error:canRetry is true (.T.).
cargo (Assignable) :
User-definable variable.
Contains a value of any data type unused by the Error system. It is provided as a user-definable slot, allowing arbitrary information to be attached to an Error object and retrieved later.
description (Assignable) :
Character description of the error condition.
Contains a character string that describes the error condition. A zero-length string indicates that the subsystem does not provide a printable description for the error. If Error:genCode is not zero, a printable description is always available.
filename (Assignable) :
Name of the file associated with the error
Contains a character value representing the name originally used to open the file associated with the error condition. A zero-length string indicates either that the error condition is not associated with a particular file or that the subsystem does not retain filename information.
genCode (Assignable) :
Error code number.
Contains an integer numeric value representing a CA-Clipper generic error code. Generic error codes allow default handling of similar errors from different subsystems. A value of zero indicates that the error condition is specific to the subsystem and does not correspond to any of the generic error codes. The header file, Error.ch, provides a set of manifest constants for generic error codes.
operation (Assignable) :
Character description of the failed operation.
Contains a character string that describes the operation being attempted when the error occurred. For operators and functions, Error:operation contains the name of the operator or function. For undefined variables or functions, it contains the name of the variable or function. A zero-length string indicates that the subsystem does not provide a printable description of the operation.
osCode (Assignable) :
Operating system error code number
Contains an integer numeric value representing the operating system error code associated with the error condition. A value of zero indicates that the error condition was not caused by an error from the operating system. When Error:osCode is set to a value other than zero DOSERROR() is updated with the same value.
Error:osCode properly reflects the DOS extended error code for file errors. This allows proper distinction between errors which result from sharing violations (e.g., opening EXCLUSIVE when another process has already opened the file) and access violations (e.g., opening read/write when the file is marked read-only).
For a list of DOS error codes please look at here
severity (Assignable) :
Indicates error severity
Contains a numeric value indicating the severity of the error condition. Four standard values are defined in Error.ch:
Error:severity Values ------------------------------------------------------------ Error.ch Meaning ------------------------------------------------------------ ES_WHOCARES The condition does not represent a failure; the error is informational. ES_WARNING The condition does not prevent further operations, but may result in a more serious error later. ES_ERROR The condition prevents further operations without corrective action of some kind. ES_CATASTROPHIC The condition requires immediate termination of the application.
------------------------------------------------------------
Note that the Clipper runtime support code only generates errors with severities of ES_WARNING or ES_ERROR
subCode (Assignable) :
Subsystem-specific error code number.
Contains an integer numeric value representing a subsystem-specific error code. A value of zero indicates that the subsystem does not assign any particular number to the error condition.
subSystem (Assignable) :
Character description of the subsystem generating the error.
Contains a character string representing the name of the subsystem generating the error. For errors with basic CA-Clipper operators and functions, the subsystem name “BASE” is given. For errors generated by a database driver, Error:subSystem contains the name of the database driver
tries (Assignable) :
Number of times the failed operation has been attempted.
Contains an integer numeric value representing the number of times the failed operation has been attempted. When Error:canRetry is true (.T.), Error:tries can be used to limit the number of retry attempts. A value of zero indicates that the subsystem does not track the number of times the operation has been tried.
Examples :
. This example demonstrates how a file open operation might be handled in an error handler replicating the default CA-Clipper behavior. When, for example, an attempt to open a database file with a USE command fails, control returns to the statement following the offending command:
#include "Error.ch"
#command RETRY => RETURN (.T.) // Retry operation #command RESUME => RETURN (.F.) // Default recovery
//
FUNCTION MyError( objError ) // // Handle file open error IF objError:genCode == EG_OPEN .AND.; objError:canDefault .AND.; NETERR() // RESUME ENDIF . . <other error statements> . RETURN NIL
. This example retries an operation within an error handler a specified number of times:
#include "Error.ch" #command RETRY => RETURN (.T.) // Retry operation #command RESUME => RETURN (.F.) // Default recovery //
FUNCTION MyError( objError ) // Handle printer not ready error IF objError:genCode == EG_PRINT .AND.; objError:canRetry .AND.; objError:tries < 25 RETRY ENDIF . . <other error statements> . RETURN NIL
. This code fragment returns an error object from an error handler to the RECOVER statement for further processing:
LOCAL objLocal, bLastHandler
// Save current and set new error handler
bLastHandler := ERRORBLOCK({ |objErr| ; MyHandler(objErr, .T.)})
BEGIN SEQUENCE . . <operation that might fail> . RECOVER USING objLocal . . <send messages to objLocal and handle the error> . END
// Restore previous error handler
ERRORBLOCK( bLastHandler )
FUNCTION MyHandler( objError, lLocalHandler ) // Handle locally returning the error object IF lLocalHandler BREAK objError ENDIF . . <other statements to handle the error> . RETURN NIL
Files: Header file is Error.ch, default error handler is in Errorsys.prg.