Basics chapter Foundation

This chapter gives an overview about each function group and contains basic information about usage of functions of various function groups. It also provides some knowledge about the underlying mechanisms inherent to the operating system which may be required for a thorough understanding of the XbToolsIII functions. Differences between XbToolsIII and CA-Tools III are outlined as well.

The text mode window system is comprised of the W...() function group the most important of which is the WInit() function. When you intend to use the text mode window system make sure to call WInit() once at startup of your program. Note that this is different to CA-Tools III. If you want to share the same code basis between DOS and OS/2 or Windows, respectively, you should enclose the WInit() call in a conditional compile structure:

 PROCEDURE Main 
    #ifdef __XPP__ 
       WInit() 
    #endif 

    <your code> 

The Xbase++ compiler implicitly defines the constant __XPP__ so this is the way to go if the same program code is to be compiled either with Xbase++ / XbToolsIII or with CA-Clipper / CA-Tools III.

In XbToolsIII the text mode window system is based on a VCrt Object. This object is a special output device for the VIO operating mode and manages a virtual screen (refer to the VCrt Class in the Xbase++ documentation). It follows a generic approach for windowing and is used in the reimplementation of the W..() functions known from CA-Tools III. However, VCrt objects are hidden from the programmer in that all text mode windows are accessed and identified by a numeric window handle (window ID). Thus, the basic programming pattern for using windows is given by the functions WOpen(), WSelect() and WClose():

nWin1 := WOpen( 6, 6, 15, 20, .T., "N/BG", 0 ) 
@ 0, 0 SAY "Hello World" 

nWin2 := WOpen( 10, 15, 22, 35, .T., "R/W", 2 ) 
@ 0, 0 SAY "Hi folks" 

WSelect( nWin1 ) 
@ 0, 0 SAY "First window selected again" 

WClose( nWin1 ) 
WClose( nWin2 ) 

The return value of WOpen() must be assigned to a variable in order to select a window and have consecutive screen output restricted to that window. When a window is selected all screen related functions use this particular window. This applies to functions like Row(), Col(), MaxRow() as well as SetCursor(), SetColor() or SaveScreen(). The screen coordinates start at the upper left corner of the window not at the upper left corner of the screen. The exception is when the root window is selected using WSelect(0). The numeric window ID 0 is reserved for the root window which represents the physical screen. If the root window is selected, all screen functions work like described in the Xbase++ documentation.

With respect to screen output there is a particular difference in the XbToolsIII window system compared to CA-Tools III. No screen output is possible at coordinates outside a window. This affects the display of a title in a framed window (a frame is drawn with WBox()). With CA-Tools III you could display a window title at the row coordinate -1. This is not possible with XbToolsIII. Here, the function WSetTitle() must be used for this particular purpose.

A major enhancement in XbToolsIII is that windows are "mouse aware". Function WMouseSelect(.T.|.F.) was added to determine whether or not windows can be detected and selected with a left mouse click. So you can program both, modal and modeless windows. Once mouse selection is activated (-> WMouseSelect(.T.)) function AppEvent() returns the event code xbeXT_WSelect plus the window IDs of the new and the current window in its first and second message parameters. The default behavior is that the clicked window gets selected. However, you can specify a codeblock with SetAppEvent( xbeXT_WSelect ) that implements a different behavior (refer to the NONMODAL.PRG sample program).

Windows can be moved either with the mouse by clicking on the window frame or with the keyboard using the cursor keys. To enter the window move mode for the keyboard CA-Tools III uses the Scroll-lock key. This is not the case in XbToolsIII. Here, the key combination Alt+F7 is used to start moving windows around with the cursor keys.

All functions of this group cannot be used in XbpDialog windows. If you use extended text mode functions and want your application to run in GUI mode, your application window must be an XbpCrt window.

Several CA-Tools III functions directly access the hardware via interrupts or BIOS and are not supported in XbToolsIII. This applies to keyboard input and print output which is managed by device drivers under 32-bit operating systems. Different video modes, like EGA 43 lines or VGA 50 lines, are emulated using a VCrt object. The same is true for video pages used for fast screen output under DOS. When your program calls functions like GetPage() oder SetPage() it actually switches between VCrt objects, not between video pages of your graphics adapter. So there is no considerable gain in performance over normal screen output when using screen pages.

A serial port (COM port) is the only means for bidirectional exchange of data between two workstations. Functions in the Serial Port group allow access to COM ports for serial communication or manipulation of devices connected to a COM port. The most important functions used to establish a serial communication are Com_Open() (opens a COM port), Com_Init() (sets transmission parameters), Com_Read() (reads data from the input buffer), Com_Send() (writes data to the output buffer) and Com_Close() (closes a COM port). These functions cover the basic requirements for a program to send and receive data via a COM port. A subset of functions is provided for the specific requirements of data exchange via modem. This includes detection of signals like Data Carrier Detect (DCD) or Ready To Send (RTS) as well as functions to ensure correct transmission of data like building a block for the X-Modem protocol or calculating a Cyclic Redundancy Checksum (CRC).

Programmers coming from DOS must be aware of the fact that modern operating systems handle COM ports differently than DOS. Therefore the behavior of the XbToolsIII functions may slightly differ from the behavior of their DOS (CA-Tools III) complements. CA-Tools III functions directly manipulate the hardware while XbToolsIII functions communicate with a device driver. This makes the XbToolsIII functions dependent on the capabilities of the device driver installed. The information about the most important signals like RTS, CTS, DSR, DTR, DCD and RI is correct no matter what driver is installed. However, existing DOS applications that rely on the contents of hardware registers like LSR, MSR or MCR might have a problem if they are ported to a 32-bit operating system because the return values of functions Com_SMode(), Com_LSR(), Com_MSR() and Com_MCR() can differ. Also, all CA-Tools III functions which directly access the hardware are obsolete under 32-bit operating systems and are not supported in XbToolsIII.

It is important to initialize the COM ports with the same communication parameters like baud rate, data bits, stop bits etc. and the baud rate not set too high. It is a good practice to use a communication protocol for data exchange, like the X-Modem protocol, so the receiving workstation can detect when transmission starts, when it ends, how many data is transmitted and it should acknowledge reception of data to the sending workstation. This is especially important when your program uses a separate thread to monitor a COM port for incoming data in the background. On the receiving workstation you have no control about the time when data arrives and you will not know whether data is waiting unless you read the receive buffer with Com_Read(). All characters read are deleted from the receive buffer. It is not possible to read the same data twice so you should always assign the return value of Com_Read() to a variable for further processing.

Windows note: it is possible under Windows to detect incoming data without retrieving them from the receive buffer. Function Com_Event() is used for this purpose which is not available under OS/2.

OS/2 note: If you encounter problems under OS/2 when establishing a serial communication between two workstations make sure to have the device drivers properly installed (we can recommend Ray Gwinn's SIO/VSIO drivers for OS/2).

When your application program expects to receive data from another workstation or from a device connected to a COM port you probably want to have a thread running to wait for incoming data while your application performs some other tasks. This is by far the most comfortable way to receive data which you don't know when they will arrive. The background thread looks every other second whether data arrived and 'sleeps' in between. Once it receives data it continues to call Com_Read() until the sender signals End of Transmission. The only problems to solve in this scenario is how to get the received data into the main thread and how to stop the background thread if this is required. The following code fragment shows a solution:

#define S_ACK   Chr(6)             // Acknowledge 
#define S_EOT   Chr(4)             // End of transmission 

PROCEDURE Main                     // Main thread 
   LOCAL aInput, aQueue, oThread, i, imax 

   PUBLIC lStopThread := .F.       // Global trigger for thread 

   aQueue  := {}                   // Array to store received data 
   oThread := Thread():new() 
   oThread:setPriority( PRIORITY_ABOVENORMAL ) 
   oThread:start( "ReceiveData", aQueue ) 

   DO WHILE <condition>            // Execute foreground tasks 
      <code for main application thread> 

      IF ! Empty( aQueue )         // Thread received data 
         lStopThread := .T.        // Tell thread to stop 
         oThread:synchronize( 0 )  // Wait until thread stops 
         aInput := aQueue          // Assign array reference 
         aQueue := {}              // Create new array reference 
         lStopThread := .F.        // Continue to receive data 
         oThread:start( "ReceiveData", aQueue ) 

         imax := Len( aInput )     // Process received data 
         FOR i:=1 TO imax          // main thread 
            <do something with aInput[i]> 
         NEXT 
      ENDIF 
   ENDDO 
RETURN 


PROCEDURE ReceiveData( aQueue )    // Procedure runs parallel 
   LOCAL cData, cBuffer := ""      // to the main thread 

   DO WHILE .NOT. lStopThread      // PUBLIC variable triggers loop 
      cData := Com_Read( 2, 1 )    // Read one byte from COM port 2 
      IF cData == S_ACK            // Transmission starts 
         DO WHILE ! (cData := Com_Read( 2, 1 )) == S_EOT 
            cBuffer += cData       // Read until End of Transmission 
         ENDDO 
         AAdd( aQueue, cBuffer )   // Add to array of main thread 
         cBuffer := ""             // Clear buffer 
      ELSE 
         Sleep( 50 )               // No transmission, sleep 1/2 second 
      ENDIF 
   ENDDO 

RETURN 

This code is a rough outline to demonstrate the basic program logic of a background thread used to monitor a COM port for incoming data. A PUBLIC variable, which is visible in both threads, is used to trigger the execution of the thread that runs the procedure ReceiveData(). A LOCAL array aQueueis passed via the Thread:start() method to this procedure. It runs parallel to the main thread and the array is used like a queue to collect incoming data. Once the main thread has time to process received data it stops the background thread by setting the PUBLIC variable to .T. and waits until the background thread finishes. The array aQueue is then assigned to another LOCAL variable of the main thread. After aQueue is initialized again with an empty array the background thread continues to receive data while the main thread processes received data.

One prerequisite for this program to work is a transfer protocol that signals at least the start and the end of transmission. Refer to the ..\SAMPLES\COMLINK sample programs for a more sophisticated transfer protocol.

The String Functions group contains an extensive number of functions for various and complex string operations. This includes formatting of strings for screen output, search and replace operations as well as string conversion routines. Most of the functions work with strings on the base of characters just like the Xbase++ functions At() or Stuff().

A special subset of functions treat strings on binary basis and allow logical operations to be performed with strings, like CharAND() or CharXOR(). For example, assume two variables cChrA := "A" and cChrZ := "Z". Then logical operations with both variables would result this:

                cChrA   = A  Decimal =  65   Binary = 01000001 
                cChrZ   = Z  Decimal =  90   Binary = 01011010 

CharAND( cChrA, cChrZ ) = @  Decimal =  64   Binary = 01000000 
CharOR ( cChrA, cChrZ ) = [  Decimal =  91   Binary = 01011011 

It is obvious that logical operations are actually performed on the bits set in the numeric ASCII code of a character.

Searching strings and string comparison using wild card characters is possible with Like(), CSetAtLike() and the At...() functions. Together with the SET LEXICAL ON|OFF switch of Xbase++ you have enhanced flexibility for "not exact but close to" search routines with strings.

For the analysis of strings an incremental tokenizer is available that is especially useful for large strings. A string is first passed to TokenInit() and then tokenized using the TokenNext() function. Nested calls to the tokenizer are possible using SaveToken() and RestToken() to save and restore the tokenizer environment. (Refer to the ..\SAMPLES\TOKEN directory for comprehensive examples of the tokenizer).

Most of the functions of the Numbers and Bits group are useful for numeric conversions or allow bitwise operations on binary strings. It is possible to directly manipulate single bits of a binary string or to convert bits set in an integer to a string containing a series of "1" and "0".

Special purpose functions are included in this group which solve some common programming problems, like creating random numbers or maintaining counters.

All tasks of the Video Functions group are related to video modes and text mode screen output as known under DOS. Therefore they are all restricted to full screen sessions or XbtCrt windows and cannot be used in a XbpDialog window. The subset of functions dealing with fonts is even more restricted to applications running in full screen sessions. These functions manipulate hardware fonts which is not possible when a program runs in a XbpCrt window.

The display of a single character on the screen requires two bytes, the character itself and a color attribute. Usually a string containing color attributes is created with the SaveScreen() function. Characters visible on screen are found at odd positions in a screen string and color attributes at even positions. Thus, the two string functions CharOdd() and CharEven() are useful to extract text and color information from a screen string. The function ScreenMix() can then be used to mix text and color attributes and "assemble" a screen string ready for display using RestScreen().

Direct manipulation of color attributes is possible as well as manipulation of displayed characters. This allows you, for instance, to color mark words in MemoEdit() or to change characters on the screen without changing the colors. This kind of screen output neither changes the cursor position nor does it affect the SetColor() setting.

Functions for Disks and Drives are useful when you need to get information about available drives (hard disk or floppy drives), directories and files. You can easily determine whether a floppy drive is ready for write access or if there is enough storage space left. Functions in this group handle runtime errors created by the operating system when a drive is not ready or if a directory does not exist.

The comfortable FileSeek() function allows you to process a group of files matching a given file mask and/or file attributes. The initial call to FileSeek() creates an internal buffer with information of all files matching the search conditions and returns the first file name found. Consecutive calls to the function return the next file name until the last one is reached. The functions SaveFSeek() and RestFSeek() are used for nested calls to save and restore the FileSeek() environment. This allows you to recurse through subdirectories and process an entire directory tree.

A special FileCopy() function is available to perform a fragmented copying of files to several disks. If a file is too large to fit on a single disk FileCopy() can be used in backup mode. It stops copying when the disk is full. The user can then be asked to change the disk and the program can continue copying by calling the FileCCont() function.

Functions in this group are used for spooler management and sending data to a printer. Before calling a printer function be sure to have a printer object properly installed and configured on your desktop (refer to your user manual for printer configuration). Without a correct configured printer object the XbToolsIII printer functions are not guaranteed to perform their tasks correctly.

Unlike DOS, a modern operating system utilizes a spooler by default for sending data to a printer. This has the advantage that an application does not need to wait until a print job is finished. Once a print job is created by an application the spooler takes responsibility for the printout and the application program can continue with other tasks. Although this is comfortable for a programmer it can lead to confusion when testing the readiness of a printer with the PrintReady() function. When a spooler is active this function returns .T. (true) even if the physical printer is not ready. The spooler then signals its readiness to receive data for a printer from the application program. In this case it is the spooler's resposibility to check the readiness of the physical printer and it prompts an error message if the printer is not ready. This again is extremely advantageous for programmers because they do not need to implement code for standard printer errors.

With its PRINT utility program DOS supports only one spool queue and so do the CA-Tools III printer functions. Since 32-bit operating systems can handle more queues at a time all XbToolsIII printer functions have an additional parameter to specify the printer used to print. Unlike the CA-Tools III function SpoolEntry() the XbTools implementation does not stop the spooler and function SpoolActiv() does not resume a paused print job. To control the spooler a new function SpoolControl() exists. It allows you to:

- delete a print job from the queue

- pause the print device

- continue a paused print job

- restart a print job

Functions SpoolAdd() and SpoolControl() give you maximum flexibility for directing print jobs to a particular printer and let you take full advantage of the comfortable spool device. Although Print..() functions exist in XbToolsIII to send data to a printer they write them to a spooler if one is active. So the function call PrintSend(MemoRead(<fileName>)) actually behaves like a SpoolAdd(<fileName>) except that SpoolAdd() sets the correct print job title.

Functions of the Date and Time group deal with seconds, days, months, quarters and years. You can determine the first or last day of a given quarter of a year or calculate a day's number from its date. All these functions are useful in solving common accounting problems or for analysis of time based statistics.

Functions in this group merely exist for compatibility reasons, so existing CA-Clipper code can be compiled without a problem. The database and field information returned by these functions can be easily retrieved with the DbInfo() and FieldInfo() functions of Xbase++.

Most of the Settings and Status functions are functional equivalents of SET commands used to define system settings. This allows settings to be queried or set from within a codeblock and is an alternative to the Set() function in conjunction with a #define constant from SET.CH.

Useful information about a program's system environment is retrieved by functions of this group. You can query the command line parameters at any time in your application, get the full qualified file name of the EXE, or determine the entire system variables set in the CONFIG.SYS file (Note that LIBPATH is not an environment setting).

The functions NumFiles(), FilesFree() and FilesMax() used to determine file handle limitations within DOS CA-Tools III exist for compatibility reasons. The maximum number of files that can be open at a time is limited by the operating system. Return values of FilesFree() and FilesMax() may vary when the requirements for file handles are adjusted by Xbase++.

In this group functions with a quite specific purpose are listed. With KbdStat(), for instance, you can determine whether or not a Ctrl, Alt, or Shift key is pressed at the moment, or you can retrieve the keyboard scan code for the last key pressed. However, the latter is not recommended to be used. Instead, only the Xbase++ function AppEvent() should be used to retrieve keyboard events from the event queue.

The Mathematical Functions group consists mainly of financial functions (to calculate future and present values or interest rates for loans) and trigonometric functions. Both types of functions require iterations to compute a result. Especially the trigonometric functions imply an increasing amount of calculations the more precise the result should be. For this reason the precision for trigonometric functions can be adjusted to a given task in order to gain maximum computing speed.

This group contains some utility functions for Get entry fields useful especially when a programmer prefers the @...GET command for programming Get entry screens.

The bindery is a small database resident on each Novell NetWare file server. It contains vital information about users, groups, queues other servers etc. and is composed of what is called Bindery Objects. A bindery object (object for short) is identified by its name and type, it has properties associated with it and each property can have either a single value (property item) or multiple values (property set). Values of properties could be strings, like the PASSWORD property, or again could be objects. For instance, the GROUPS_I'M_IN property set is a list of objects of the GROUP type a user belongs to (don't confuse the term object with what is known from object oriented programming. Even you are an object in the bindery when you log in to a NetWare file server). As a conclusion, the bindery contains all information to maintain and run a network.

Low level Bindery Functions provide access to the bindery and allow to retrieve or change almost any information stored in the bindery. However, an appropriate security is necessary for most of the functions to work. If a function call fails make sure to have the required security set.

Some of the most common tasks in network maintenance is user and group administration. This could be achieved with the low level bindery functions but is more comfortably programmed with functions of this group. Just call NnetCrtUsr() or NnetCrtGrp() to create a new user or a new user group, or call NnetLgUser() to know who is currently logged in to the file server. So, functions of this group are convenient for the daily work in network administration.

The Connection Services group contains functions which are required for connecting/disconnecting a client workstation to/from a file server. A connection is created as a 'real login' using NnetLogin() or as a logical connection with NnetAttach(). Once a connection is established various functions can be used to retrieve information about the connection and the available file servers in the network.

Capture processes are used for network printing when several client workstations share the same printer(s) connected to a file server. After a capture process is initiated with NnetCapBeg(), the output device is defined at the client workstation, for example with SET PRINTER TO LPT1. The capturing intercepts all data sent to the local printer port and redirects it to the file server where it is stored in a capture file. A call to NnetCapEnd() terminates the capturing and the capture file is sent to the network printer via the NetWare queue management system. Note that a particular print queue can be specified using the NnetSetQ() function if capturing should be processed in a print queue other than the default one (see Print Queue functions).

Functions of the Drive Administration group allow to map paths to logical drives both permanently and temporarily. Path mappings can be set or released so an Xbase++ application can define its own network environment.

Maintenance of directories and files which reside on a file server volume is possible with Server Administration functions. You can create or remove directories on a server volume, copy files between volumes or get information about entire subdirectories. If a user has supervisory rights it is also possible to define Trustee rights on directory or file level.

Print Queue functions allow access to the Novell print queue management system which gives maximum control for shared printing in a network. A print queue itself is a bindery object which has properties holding information about the queue operators, queue users, queue servers as well as print jobs in the queue. Each of these properties can be created or specified, modified or deleted using Print Queue functions.

A print queue is first created with the NnetCrtQ() function, then queue operators, users and print server must be specified with NnetAddQOp(), NnetAddQUs() and NnetAddQSv(). A queue operator is a user with special rights, like changing the status of a queue and prioritize or reorder jobs, whereas only queue users may place jobs in the print queue. The function NnetSetQ() then defines the new print queue as the one to process capture files (see Capture Processes). Once a capture file is placed in a print queue numerous functions can be used to retrieve (or change) job related information.

With its utility program PRINTCON.EXE Novell NetWare allows to configure standard print jobs. Configuration data is stored in the PRINTCON.DAT database file and is retrieved when selecting a default print job configuration to be used for capture processes.

The PRINTCON.DAT file can be accessed using functions of the Print Job Configuration group. This means, print job configuration records can be added, edited or deleted from the file, and can be selected as the default job configuration.

A print job sent from a client workstation is stored temporarily in a print queue on the file server before it actually gets printed. It is then the print server's responsibility to take print jobs out of a print queue and send them on to a physical printer when this is ready to print. Functions of the Print Server group are used to access a print server and to retrieve information about it. This includes information about the current job being printed as well as status information about a printer serviced by the print server. Also, bindery objects can be defined (normally users) to receive notification messages from the print server when a job is done or if the printer is out of paper.

A semaphore can be viewed as a numeric variable visible to all client stations connected to a file server. An application running on a client workstation can open, examine, wait for (=decrement), signal (=increment) and close a semaphore. Thus, semaphores are useful when applications simultaneously access resources located on a file server and the application must be able to detect whether or not the same resource is used by another client workstation. This allows, for instance, to limit the number of users running an application at the same time to a fixed amount.

As with files opened with FOpen(), a semaphore is opened passing a name to the NnetSemOpn() function which returns a numeric handle to the semaphore. When the application wants to access a semaphore protected resource, it calls NnetSemWai(), does the desired operations with that resource and calls NnetSemSgn() to signal to other client stations that the resource is no longer in use. When the semaphore is no longer required it is closed by calling NnetSemClo().

There are seven functions available in XbToolsIII that let you take advantage of NetWare's Transaction Tracking System (TTS). With its TTS, NetWare guarantees a set of data writes to be entirely written to a database or to be voided once a transaction fails to complete, thus leaving a database in its pre-transactional state. All files that are to be monitored by the TTS must be marked as transactional. Use the FILER.EXE utility or function NnetExtAtt() to set the EXA_TTS extended file attribute for all files participating in TTS. This includes database (DBF), memo (DBT) and index (NTX) files.

Note

When you intend to use the TTS we strongly recommend you to disable NetWare's implicit transactions, otherwise your application might loose control over the start and the end of transactions. Type SETTTS 255 255 on the command line of a logged in client workstation to disable implicit transactions. Also, you must design your application to fit into NetWare's TTS. This means, your application must be aware of the fact that a physical lock is set by NetWare on a changed database record.

As a general rule, NetWare's TTS locks a record physically and Xbase++ locks a record logically. Do not confuse logical and physical locks when using TTS functions. For shared access to a database you must lock a record logically (function Rlock() or DbRlock()) before Xbase++ allows you to change a record. When the database participates in NetWare's TTS (function NnetTTSBeg()) a changed record becomes unreadable to other workstations until the transaction is complete (function NnetTTSEnd()). The reason for this is that NetWare sets a physical lock on a changed record. Any access to a record that is part of a transaction and is physically locked results in a runtime error in your Xbase++ application on all workstations other than the one that initiates the transaction. As a consequence, even when you read a database field you must protect your application against runtime errors using a BEGIN SEQUENCE... RECOVER... END structure or you should use semaphores before you start a transaction (refer to the TRANSACT.PRG sample program found in ..\SAMPLES\NETWARE)

This group contains a variety of functions to retrieve information about the file server and its environment. The two functions HexToStr() and StrToHex() are no network functions but used for converting strings from binary to hexadecimal format. This is useful, for instance, to decode the internet address of a workstation as returned by the function NnetAdr().

Functions in this group are used to establish direct communication between client workstations in a network using NetBIOS datagram or session services. Datagrams provide a simple transmission service with powerful broadcast capabilities. They can be sent to a named entity like a single workstation, a group of stations or to all users in a network. However, they are not reliable since they are not acknowleged or tracked through an identification number. They may or may not be received. For a secure point to point communication NetBIOS sessions can be used where exchanged data is acknowledged and tracked.

Before using NetBIOS datagram or session services function NbReset() must be called in order to allocate rescources for a process's exclusive use from the NetBIOS environment. Then logical names for workstations and groups must be added to the local name table using NbAddName() or NbAddGroup(). Note that the local name table is visible to all workstations in a network which use NetBIOS services. Function NbAddName() is used to define a unique logical name for a workstation. If this name exists already in a network it will not be added to the local name table. However, multiple workstations may add the same group name to the name table using NbAddGroup().

NetBIOS communication is based on handles (like file handles). Use function NbDOpen() to obtain a communication handle for datagram services, or functions NbSCall() and NbSListCon() to get handles for session services. While NbSCall() attempts to open a session with a specified workstation the function NbSListCon() allows to accept remote session requests (it listens for a connection), either from a named partner or from any station in the network.

Once a connection is established you can use Ppc..() functions, like PpcRead() and PpcWrite(), to exchange data via the communication handle. Outgoing data is copied to the send buffer and incoming data is stored in the receive buffer. Both buffers are limited to 64kByte in size so data can get lost if either buffer is full. Functions PpcRecCnt()/PpcSndCnt() and PpcRecFree()/PpcSndFree() are used to determine how many bytes are stored in the buffers and how many free space is left respectively.

Important

When your program calls NetBIOS functions in conjunction with multiple threads (Xbase++ Thread objects) you can use a communication handle obtained with NbdOpen(), NbSCall() or NbSListCon() only in the thread that has executed either of these functions. As a consequence, a particular communication handle can be used only by one thread. However, you may establish multiple connections from multiple threads between the same workstations.

The Printer and Forms functions access the NetWare database which is normally administered with the utility PRINTDEF.EXE. It contains configuration data about printers and forms. Thus an Xbase++ application can take advantage of standard configurations for network printers.