fivedev/harbour-core
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

2012-11-15 23:08 UTC+0100 Viktor Szakats (harbour syenar.net)

Browse Source 
* doc/clipper.txt
  * doc/cmpopt.txt
  * doc/codebloc.txt
  * doc/gtapi.txt
  * doc/hdr_tpl.txt
  * doc/inet.txt
  * doc/locks.txt
  * doc/pp.txt
  * doc/pragma.txt
  * doc/todo.txt
  * doc/tracing.txt
  * doc/vm.txt
  * doc/xhb-diff.txt
    * function name formatting
    * various minor cleanups and updates/fixes along the way
This commit is contained in:
Viktor Szakats
2012-11-15 22:10:31 +00:00
parent f62b815211
commit a22bb91807
14 changed files with 145 additions and 127 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
harbour/ChangeLog
View File

@@ -16,12 +16,30 @@
The license applies to all entries newer than 2009-04-28.
*/
2012-11-15 23:08 UTC+0100 Viktor Szakats (harbour syenar.net)
* doc/clipper.txt
* doc/cmpopt.txt
* doc/codebloc.txt
* doc/gtapi.txt
* doc/hdr_tpl.txt
* doc/inet.txt
* doc/locks.txt
* doc/pp.txt
* doc/pragma.txt
* doc/todo.txt
* doc/tracing.txt
* doc/vm.txt
* doc/xhb-diff.txt
* function name formatting
* various minor cleanups and updates/fixes along the way
2012-11-15 22:50 UTC+0100 Viktor Szakats (harbour syenar.net)
* contrib/hbct/doc/en/*.txt
* contrib/hbmisc/doc/en/*.txt
* contrib/rddads/doc/en/adsfuncs.txt
* contrib/rddads/doc/en/readme.txt
! fixed library name references
! ctiii -> CT3
2012-11-15 19:41 UTC+0100 Viktor Szakats (harbour syenar.net)
* contrib/hbct/doc/en/atnum.txt

48
harbour/doc/clipper.txt
View File

@@ -10,16 +10,16 @@ CA-Cl*pper.
Harbour Macro Compiler
----------------------
The Harbour Macro Compiler offers 2 additional layers of functionality
controlled by means of HB_SETMACRO()* function, not available in CA-Cl*pper.
controlled by means of hb_SetMacro()* function, not available in CA-Cl*pper.
HB_SETMACRO( HB_SM_HARBOUR, TRUE ) will enable macro compilation and
hb_SetMacro( HB_SM_HARBOUR, .T. ) will enable macro compilation and
evaluation of complex expressions not supported by CA-Cl*pper like:
- exp++, exp--, var += exp, (exp), etc..
- Nested codeblocks.
- Expressions longer then 254 characters.
HB_SETMACRO( HB_SM_XBASE, TRUE ) will enable macro compilation and
hb_SetMacro( HB_SM_XBASE, .T. ) will enable macro compilation and
evaluation of comma separated lists in all contexts where lists are
acceptable by CA-Cl*pper*, including:
@@ -47,7 +47,7 @@ descriptions, but is the de-facto behavior in all CA-Cl*pper 5.x versions.
Harbour instead will not only evaluate all of the expressions in
such list macro, but will also display all such values. This default
behavior may be disabled with HB_SETMACRO( HB_SM_XBASE, .F. )*
behavior may be disabled with hb_SetMacro( HB_SM_XBASE, .F. )*
* See also -k Compiler switch.
@@ -71,22 +71,22 @@ Harbour has support enumeration loop with the following syntax:
NEXT
Note:
-expr can be a string or an array
-enumerator variable 'var<n>' stores a reference to the element of
an array or a string specified by 'expr<n>' thus assigments to the
enumerator changes the value of given array element
-after the loop the controlling variable(s) store the value which
they had before entering the loop
-the enumeraqtor variable supports the following properties
:__enumindex - the loop counter for variable
:__enumbase - the value that is being traversed
:__enumvalue - the value of variable
- expr can be a string or an array
- enumerator variable 'var<n>' stores a reference to the element of
an array or a string specified by 'expr<n>' thus assigments to the
enumerator changes the value of given array element
- after the loop the controlling variable(s) store the value which
they had before entering the loop
- the enumeraqtor variable supports the following properties
:__enumindex - the loop counter for variable
:__enumbase - the value that is being traversed
:__enumvalue - the value of variable
for example:
a = 'A'
b = 'B'
FOR EACH a,b IN { 1, 2, 3, 4 }, "abcd"
a := 'A'
b := 'B'
FOR EACH a, b IN { 1, 2, 3, 4 }, "abcd"
? a, b //prints: 1 a
// 2 b
// 3 c
@@ -96,7 +96,7 @@ for example:
// you can use EXIT statement inside the loop
FOR EACH a IN { 1, 2, 3, 4 }
IF( a:__enumindex == 3 )
IF a:__enumindex == 3
? a
EXIT
ENDIF
@@ -106,10 +106,10 @@ for example:
str := "abc"
FOR EACH a, b IN arr, str
a *= 2
str := UPPER( str )
str := Upper( str )
NEXT
//now 'arr' stores { 2, 4, 6 }
//howerer 'str' still stores "abc"
// now 'arr' stores { 2, 4, 6 }
// howerer 'str' still stores "abc"
Notice the difference:
FOR EACH a IN someValue
@@ -133,14 +133,14 @@ Harbour supports the following statement:
to send messages to the object specified by 'expression'
for example:
WITH OBJECT myobj:a[1]:myitem
WITH OBJECT myobj:a[ 1 ]:myitem
:message( 1 )
:value := 9
ENDWITH
The above code is equivalent to:
myobj:a[1]:myitem:message( 1 )
myobj:a[1]:myitem:value := 9
myobj:a[ 1 ]:myitem:message( 1 )
myobj:a[ 1 ]:myitem:value := 9
Inside WITH OBJECT/END you can access (or even assign a new object)
using a special reserved property :__withobject

48
harbour/doc/cmpopt.txt
View File

@@ -13,34 +13,34 @@ optimized at compile time:
- Clipper compatible:
AT( <cConst1>, <cConst2> ) // Clipper wrongly calculates
// AT( "", <cConst> ) as 1
ASC( <cConst> [ , ... ] )
CHR( <nConst> )
LEN( <cConst> | <aConst> | <hConst> ) // <hConst> is Harbour extension
UPPER( <cConst> ) // <cConst> cannot contain characters different then
At( <cConst1>, <cConst2> ) // Clipper wrongly calculates
// At( "", <cConst> ) as 1
Asc( <cConst> [ , ... ] )
Chr( <nConst> )
Len( <cConst> | <aConst> | <hConst> ) // <hConst> is Harbour extension
Upper( <cConst> ) // <cConst> cannot contain characters different then
[0-9A-Za-z ]
- Harbour extension:
INT( <nConst> )
MIN( <xConst1>, <xConst2> ) // <xConstN> is N, D or L value
MAX( <xConst1>, <xConst2> ) // <xConstN> is N, D or L value
EMPTY( <aConst> | <hConst> | <cConst> | <bConst> |
Int( <nConst> )
Min( <xConst1>, <xConst2> ) // <xConstN> is N, D or L value
Max( <xConst1>, <xConst2> ) // <xConstN> is N, D or L value
Empty( <aConst> | <hConst> | <cConst> | <bConst> |
<nConst> | <dConst>| <lConst> | NIL )
CTOD( "" [ , ... ] )
DTOS( <dConst> ] )
STOD( [ <cConst> ] )
HB_STOD( [ <cConst> ] )
HB_STOT( [ <cConst> ] )
HB_BITNOT( <nConst> [, ... ] )
HB_BITAND( <nConst1>, <nConst2> [, <nConstN> ] )
HB_BITOR( <nConst1>, <nConst2> [, <nConstN> ] )
HB_BITXOR( <nConst1>, <nConst2> [, <nConstN> ] )
HB_BITTEST( <nConst1>, <nConst2> [, ... ] )
HB_BITSET( <nConst1>, <nConst2> [, ... ] )
HB_BITRESET( <nConst1>, <nConst2> [, ... ] )
HB_BITSHIFT( <nConst1>, <nConst2> [, ... ] )
CToD( "" [ , ... ] )
DToS( <dConst> ] )
SToD( [ <cConst> ] )
HB_SToD( [ <cConst> ] )
hb_SToT( [ <cConst> ] )
hb_bitNot( <nConst> [, ... ] )
hb_bitAnd( <nConst1>, <nConst2> [, <nConstN> ] )
hb_bitOr( <nConst1>, <nConst2> [, <nConstN> ] )
hb_bitXor( <nConst1>, <nConst2> [, <nConstN> ] )
hb_bitTest( <nConst1>, <nConst2> [, ... ] )
hb_bitSet( <nConst1>, <nConst2> [, ... ] )
hb_bitReset( <nConst1>, <nConst2> [, ... ] )
hb_bitShift( <nConst1>, <nConst2> [, ... ] )
- Harbour special functions:
@@ -48,7 +48,7 @@ optimized at compile time:
HB_I18N_NGETTEXT_NOOP( <nCount>, <cConst1> | <acConst1> [ , <cConst2> ] )
HB_I18N_GETTEXT_NOOP_*( <cConst1> [ , <cConst2> ] )
HB_I18N_NGETTEXT_NOOP_*( <nCount>, <cConst1> | <acConst1> [ , <cConst2> ] )
HB_MUTEXCREATE()
hb_mutexCreate()
2. Expresion optimization:

4
harbour/doc/codebloc.txt
View File

@@ -56,8 +56,8 @@ PROCEDUE Main()
PRIVATE foo, bar
Test()
EVAL( foo )
EVAL( bar )
Eval( foo )
Eval( bar )
PROCEDURE Test()
LOCAL a := "FOO", b := "BAR"

18
harbour/doc/gtapi.txt
View File

@@ -83,7 +83,7 @@ _gtSave
_gtRestore
Two Harbour functions are included in the gtapi.c file,
ROW() and COL() to get started.
Row() and Col() to get started.
You also may notice that I didn't include any NanFor document headers or
even any cvs macros. The jury is still out on that so I'll leave that to the
@@ -115,7 +115,7 @@ which operate on GT resources.
Harbour application can work without any GT driver. In such case all
functions which operates on GT resources are redirected to meta GT
driver (GTNUL) which is part of RTL library. This driver makes all
operations on memory buffer and only OUTSTD()/OUTERR() output is sent
operations on memory buffer and only OutStd()/OutErr() output is sent
outside. All GT drivers inherits from GTNUL or from other GTs but in
the inheritance chain the first GT driver is always GTNUL.
@@ -141,7 +141,7 @@ or:
PROCEDURE RDDSYS(); RETURN
Both gives the same effect, and default RDD (DBFNTX) will not be linked.
Exactly the same I've done in GT subsystem. HB_GTSYS() makes exactly
Exactly the same I've done in GT subsystem. hb_GTSYS() makes exactly
the same job as RDDSYS() but for GT. This symbol is requested by core
code and in the module where it is defined it request default build GT
driver or if it's not set then default GT driver for given platform.
@@ -157,7 +157,7 @@ the same as for RDD and add to your code:
ANNOUNCE HB_GTSYS
or:
PROCEDURE HB_GTSYS(); RETURN
PROCEDURE hb_GTSYS(); RETURN
In such case your final application will not have any GT driver. If you
want to use GTNUL as base, you should add:
@@ -216,7 +216,7 @@ other situations when it could be useful to have full functional GT
driver in GUI application. You can even create mixed GUI/CUI code in one
program.
And finally, the TONE() function problem.
And finally, the Tone() function problem.
Low level TONE code is part of GT driver. In the past, GUI libraries in
Windows were linked the whole GTWIN driver and only TONE were used. It
was possible because someone blocked GTWIN to work with application
@@ -239,7 +239,7 @@ NOTE: src/rtl/gtgui/gtdef.c is a hack which overloads the default
gtnul - base GT driver from which each other inherits.
it gives screen buffer functionality but does not
produce any screen output from disp*() commands
Only outStd()/outErr() are supported.
Only OutStd()/OutErr() are supported.
It's present on all platforms and i always linked.
gtcgi - very simple GT driver which does not make any output
@@ -331,16 +331,16 @@ gtalleg- GT driver which uses alegro library for input/output.
gtgui - pseudo GT driver which adds to GTNUL Clipboard and Tone
functionality. If you are using some MS-Windows GUI library
and you still want to use TONE() function or GTI_CLIPBOARD
and you still want to use Tone() function or HB_GTI_CLIPBOARD
actions then link this GT driver with your application.
If you do not want to use TONE() or GTI_CLIPBOARD then
If you do not want to use Tone() or HB_GTI_CLIPBOARD then
do not link it - it will be only waste of memory.
gtctw - GT driver which adds CT3 Window functionality to any other
GT driver from which it inherits. It's activated automatically
when you execute first W*() function.
In similar way in Harbour it's possible to add support for
GTWVW inheriting from GTWVT.
GTWVW/GTWVG inheriting from GTWVT.
Some of the GT drivers support additional functionality with hb_gtInfo()
interface.

2
harbour/doc/hdr_tpl.txt
View File

@@ -124,7 +124,7 @@ HEADER EXAMPLES
IsLeapYr( [<dDate>] ) --> <lIsLeap>
$ARGUMENTS$
<dDate> is an optional date. If not supplied is defaults to the
value returned from date().
value returned from Date().
$RETURNS$
.T. if <dDate> falls in a leap year, .F. if not.
$DESCRIPTION$

76
harbour/doc/inet.txt
View File

@@ -37,22 +37,22 @@ please see en-EN/hbinet.txt which now replaces this file
Startup / cleanup functions
---------------------------
hb_InetInit() -->NIL
hb_inetInit() -->NIL
Activates inet support; mainly used for winsock start up at the moment, but
could be used in the future for many other purpose. Put it at the beginning
of every program using INET functions.
hb_InetCleanup() -->NIL
hb_inetCleanup() -->NIL
Closes Inet support; mainly used for Windows. Put it at the end of any program
using Inet functions, just before the program exits.
hb_InetCreate() --> SOCKET
hb_inetCreate() --> SOCKET
Creates the raw data of the socket, that can be passed to an asynchronous
connection function (hb_InetConnect or hb_InetConnectIP). This will prevent the
connection function from allocating some data that could be never used in
certain cases, i.e. an asynchronously detected timeout.
hb_InetClose( SOCKET ) --> NUMERIC
hb_inetClose( SOCKET ) --> NUMERIC
Closes the socket, notifiying both ends of the communication pipe that the
connection is over. If you have threads waiting for data to be read from
this socket, this method will make them stop waiting and return an error
@@ -71,7 +71,7 @@ please see en-EN/hbinet.txt which now replaces this file
hb_InetSetTimeout( SOCKET, nMillisecs ) --> NIL
Sets the default timeout of the given socket. Default timeout is used in all
blocking operations: if the operation can't be done in nMillisec milliseconds,
the function returns immediately and the hb_InetErrorCode( SOCKET ) returns -1.
the function returns immediately and the hb_inetErrorCode( SOCKET ) returns -1.
The default timeout is not the maximum time that a function using the socket
is allowed to execute: it is the maximum time that each single blocking
operation inside that function is allowed to hold the control of the socket.
@@ -84,43 +84,43 @@ please see en-EN/hbinet.txt which now replaces this file
hb_InetGetTimeout( SOCKET ) --> NUMERIC
Returns the timeout set for the given socket.
hb_InetClearTimeout( SOCKET, nMillisecs ) --> NIL
hb_inetClearTimeout( SOCKET, nMillisecs ) --> NIL
Clears the default timeout of the given socket. Default timeout is used in all
blocking operations.
Informative functions
---------------------
hb_InetErrorCode( SOCKET ) --> Numeric
hb_inetErrorCode( SOCKET ) --> Numeric
Returns the last error code that has been provoked by a network operation,
or 0 if none. Error codes are the ones used for winsock or UnixSockets (they
are the same); 1 is reserved for "connection closed" message.
hb_InetErrorDesc( SOCKET ) --> String
hb_inetErrorDesc( SOCKET ) --> String
Returns a string describing the last error that occurred in the socket;
the string is system dependent, and should be used only for debugging
purposes.
hb_InetCount( SOCKET ) --> Numeric
hb_inetCount( SOCKET ) --> Numeric
Returns the amount of characters read or written in the latest socket
operation.
hb_InetAddress( SOCKET ) --> STRING
hb_inetAddress( SOCKET ) --> STRING
Returns a string representing the remote server address in quad dot notation,
e.g. "192.168.1.1", or the local server address if the socket is server
side.
TODO: have a version that returns a vector of 4 numbers.
hb_InetPort( SOCKET ) --> STRING
hb_inetPort( SOCKET ) --> STRING
Returns the port to which this socket is bound, or the remote port if this
socket is connected with a remote host or client
Server Side socket functions
----------------------------
hb_InetServer( port [, cBindAddr [, nListenLimit]] ) --> SOCKET
hb_inetServer( port [, cBindAddr [, nListenLimit]] ) --> SOCKET
Creates a server that can accept connections from client on a certain port.
If the computer on which hb_InetServe is called has more than one logical
interface (e.g. one network card, one loopback and one PPP address),
@@ -141,17 +141,17 @@ please see en-EN/hbinet.txt which now replaces this file
a heavy duty server.
On error, sets error description in the newly returned socket.
hb_InetAccept( SOCKET ) --> SOCKET
hb_inetAccept( SOCKET ) --> SOCKET
Waits until a connection is available on a socket created with hb_InetServer;
Returns a socket that can be used to communicate with the incoming client.
On error, NIL is returned and error code sets in the passed SOCKET.
This error can be accessed using hb_InetErrorCode() function.
This error can be accessed using hb_inetErrorCode() function.
Client side socket functions
----------------------------
hb_InetConnect( cAddress, nPort ) --> SOCKET
hb_InetConnect( cAddress, nPort, SOCKET ) --> NIL
hb_inetConnect( cAddress, nPort ) --> SOCKET
hb_inetConnect( cAddress, nPort, SOCKET ) --> NIL
Connects to a remote server described by cAddress, that can be in
quad dot notation (e.g. "192.168.1.1") or in DNS name (e.g.
"www.xharbour.org"), using the desired port.
@@ -173,8 +173,8 @@ please see en-EN/hbinet.txt which now replaces this file
be due to unavailable name resolving service, host name not valid,
host address not reachable and host reachable but port not open.
hb_InetConnectIP( cAddress, PORT ) --> SOCKET
hb_InetConnectIP( cAddress, PORT, SOCKET ) --> NIL
hb_inetConnectIP( cAddress, PORT ) --> SOCKET
hb_inetConnectIP( cAddress, PORT, SOCKET ) --> NIL
Connects to a remote server described by cAddress, that can be specified
only in quad dot IPV4 notation (e.g. "127.0.0.1"), using the desired port.
This version of hb_InetConnect does not use gethostbyname, and thus is thread
@@ -190,7 +190,7 @@ please see en-EN/hbinet.txt which now replaces this file
Sending and receiving data
----------------------------
hb_InetRecv( SOCKET, @cString [, nAmount] ) --> NUMERIC
hb_inetRecv( SOCKET, @cString [, nAmount] ) --> NUMERIC
Reads at maximum nAmount bytes (or a number of bytes equal to cString
length if nAmount is not given) from the socket into cString.
The parameter cString must be preallocated so that it has enough
@@ -203,17 +203,17 @@ please see en-EN/hbinet.txt which now replaces this file
read before the function returns, in fact, hb_InetRecv returns as soon it
is able to fill cString with one or more bytes. To block the current
process until the whole cString is filled (or nAmount bytes are read),
use the hb_InetRecvALL().
use the hb_inetRecvAll().
RETURNS the number of the characters read from the SOCKET.
hb_InetRecvAll( SOCKET, @cString [, @nAmount] ) --> NUMERIC
hb_inetRecvAll( SOCKET, @cString [, @nAmount] ) --> NUMERIC
This function works exactly as hb_InetRecv, except for the fact that it
blocks until nAmount bytes are read, if nAmount is given, or
cString is filled for its whole length.
RETURNS the number of the characters read from the SOCKET. Might be
less than nAmount on premature socket closing or on network error.
hb_InetRecvLine( SOCKET [, @nResult, [, nMaxLength [, nBufSize]]] ) --> STRING
hb_inetRecvLine( SOCKET [, @nResult, [, nMaxLength [, nBufSize]]] ) --> STRING
Blocks the calling thread until a sequence CRLF is read from the socket.
Incremental allocation and end-of-line checking are done in an efficient
way. If an error occurs, or if the stream is closed before a CRLF is read,
@@ -234,26 +234,26 @@ please see en-EN/hbinet.txt which now replaces this file
equal to nMaxLength, memory for reading the line will be allocated only
once, at the beginning of the function).
hb_InetRecvEndBlock( SOCKET [, cBlock [, @nResult, [, nMaxLength [,
hb_inetRecvEndblock( SOCKET [, cBlock [, @nResult, [, nMaxLength [,
nBufSize]]]] ) --> STRING
This function operates exactly the same way as hb_InetRecvLine, but
the "record termination" is customizable thorugh the cBlock parameter.
If not given, this parameter defaults to the CRLF sequence.
Provided by: Marcelo Lombardo
hb_InetDataReady( SOCKET [, nMillisecs] ) --> NUMERIC
hb_inetDataReady( SOCKET [, nMillisecs] ) --> NUMERIC
Verifies if some data is available to be read in the socket without blocking
execution of the caller. If nMillisecs is not given, the function returns
immediately 1 if there is some data to be read, 0 if there isn't any data and
-1 in case of error. If nMillisecs is given, the functon will wait up to that
amount of milliseconds for data to be available; if some data arrives in the
meanwhile, the wait is immediately interrupted.
The next hb_InetRecv() function will read all the available data (up to the
The next hb_inetRecv() function will read all the available data (up to the
required length) without blocking.
On error, hb_InetErrorCode and hb_InetErrorDesc can be use to determine what kind
of error happened.
hb_InetSend( SOCKET, STRING [, nLength ] ) --> NUMERIC
hb_inetSend( SOCKET, STRING [, nLength ] ) --> NUMERIC
Send data being stored in a string over the socket. Returns the amount of
data written, 0 if the socket has been closed in the meanwhile or -1 on
error. The nLength parameter can be given to allow writing only a part of
@@ -263,43 +263,43 @@ please see en-EN/hbinet.txt which now replaces this file
take care to ensure that the data is really sent; so you should check for
the returned number, and send the part that has not been sent.
To ensure that all the data is sent before the function returns, use the
hb_InetSendAll() function.
hb_inetSendAll() function.
On error, the error in the socket is set.
hb_InetSendAll( SOCKET, STRING [, nLength ] ) --> NUMERIC
This function works exactly as hb_InetSend() but it ensures that all the
hb_inetSendAll( SOCKET, STRING [, nLength ] ) --> NUMERIC
This function works exactly as hb_inetSend() but it ensures that all the
data to be sent is written before returning.
Utility Functions
------------------
hb_InetGetHosts( cName ) --> aHosts
hb_inetGetHosts( cName ) --> aHosts
Returns an array containing all the IP addresses associated with a given
host name. The IP addressess returned by this funtion are strings in
quad dot notations, eg "192.168.1.1", and can be directly used into
hb_InetConnectIP(). cName can be any string: valid DNS names (eg.
hb_inetConnectIP(). cName can be any string: valid DNS names (eg.
"www.myserver.com"), locally available names (e.g. "localhost" or
windows Network Neighborhood names), or even IP addresses in quad
dot notation.
NOTE: This function is not thread safe (by design), and programmers
must be sure not to use it at the same time in two different threads,
or not to use it together with a hb_InetConnect(). If this kind of situation
or not to use it together with a hb_inetConnect(). If this kind of situation
should ever arise, you are advised to use a thread MUTEX.
On error, and if the server can't be found, the function returns NIL.
hb_InetGetAlias( cName ) --> aHosts
hb_inetGetAlias( cName ) --> aHosts
Returns an array containing the aliases ( CNAME DNS records ) by
which the server is currently known. Whether this function is able
to have the complete list of aliases or not depends on the verbosity
of the DNS server.
hb_InetCRLF() --> String
hb_inetCRLF() --> String
Returns a CRLF sequence used in many internet protocols.
UDP (User Datagram Protocol) Compliant Routines
-----------------------------------------------
hb_InetDGram( [bBroadcast] ) --> SOCKET
hb_inetDGram( [bBroadcast] ) --> SOCKET
Creates a datagram oriented socket that will be able to send data and
eventually receive data. Since the socket is not bound, the program can't
retrieve the address at which this socket appaers to be, but a second
@@ -311,7 +311,7 @@ please see en-EN/hbinet.txt which now replaces this file
Returns the socket, and if an error occurs, the socket error message
and code are set.
hb_InetDGramBind( nPort, [cAddress [, bBroadcast] ] ) --> SOCKET
hb_inetDGramBind( nPort, [cAddress [, bBroadcast] ] ) --> SOCKET
Creates a datagram oriented socket and binds it to a particular port, and
eventually to a certain interface if cAddress is given and not NIL.
If bBroadcast is set to .T., the routine creates a broadcast capable socket:
@@ -320,7 +320,7 @@ please see en-EN/hbinet.txt which now replaces this file
Returns the socket, and if an error occurs, the socket error message
and code are set.
hb_InetDGramSend( SOCKET, cAddress, nPort, cBuffer [, nSize ] ) --> NUMERIC
hb_inetDGramSend( SOCKET, cAddress, nPort, cBuffer [, nSize ] ) --> NUMERIC
Sends a datagram (a fixed length data) to a determined ip address (cAddress,
to be specified in quad-dot notation) and port. If nSize is not specified,
all the data in cBuffer will be sent; if nSize is specified, only
@@ -336,7 +336,7 @@ please see en-EN/hbinet.txt which now replaces this file
can be a broadcast address.
Returns -1 on error, or the number of bytes actually sent on success.
hb_InetDGramRecv( SOCKET, cBuffer [, nSize ] ) --> NUMERIC
hb_inetDGramRecv( SOCKET, cBuffer [, nSize ] ) --> NUMERIC
Reads at maximum nSize bytes incoming from a UDP socket, if nSize is
given, or reads at maximum cBuffer length if nSize is not given.
There isn't any guarantee that all the data required to be read is

6
harbour/doc/locks.txt
View File

@@ -35,19 +35,19 @@ here.
In documentation CLIP can use Clipper like or FoxPro like locking
schemes and it can be controlled by SET LOCKSTYLE [TO] ... command
or SET( _SET_LOCKSTYLE, 0 | 1 ) function.
or Set( _SET_LOCKSTYLE, 0 | 1 ) function.
This switch only changes the RLOCK/FLOCK offset.
For:
SET LOCKSTYLE [TO] CLIPPER | CLIPPER50 | CLIPPER53
or:
SET( _SET_LOCKSTYLE, 0 )
Set( _SET_LOCKSTYLE, 0 )
this offset is set to 1'000'000'000. This is header lock address
and records are locked at above address + record number.
This is compatible with standard Clipper locking.
Commands:
SET LOCKSTYLE [TO] CLIPPER52 | FOXPRO | SIX
or:
SET( _SET_LOCKSTYLE, 1 )
Set( _SET_LOCKSTYLE, 1 )
set this offset to 0x10000000 keeping the same algorithm
for record locking what is incompatible with any other locking
schemes known by me. For sure it's not compatible with [V]FP

18
harbour/doc/pp.txt
View File

@@ -67,7 +67,7 @@ making in last days.
Such quoting has very high priority like normal string quoting. f.e:
? [ ; // /* ]
should generate:
QOUT( " ; // /* " )
QOut( " ; // /* " )
This implicates one important thing: PP has to read whole physical
line from file, then convert it to tokens and if necessary (';' is the
last token after preprocessing) read next line(s).
@@ -91,14 +91,14 @@ making in last days.
#define O2 ]
? O1 b O2
should generate:
QOUT( [ b ] )
QOut( [ b ] )
not:
QOUT( " b " )
QOut( " b " )
but:
#command A <x> => ? <x>
A [ b ]
generate also:
QOUT( [ b ] )
QOut( [ b ] )
and in this case Clipper compiler makes conversion to string.
It means that only at initial line preprocessing preprocessor decides
what can or cannot be string token. I think that we do not have to
@@ -124,7 +124,7 @@ making in last days.
disable this special meaning and in such case Clipper PP
generates array tokens but they are not marked as open_array_index
when in the code they are. It causes that in code like
#command A B\[C] => QOUT("A B[C]")
#command A B\[C] => QOut("A B[C]")
A B[C]
A B[C] is not preprocessed because in #command match pattern '[' is
not open_array_index and PP cannot find matching tokens.
@@ -133,7 +133,7 @@ making in last days.
translated to string and not bound
with keyword. As I wrote above it will be possible when '[' is after
one of the closing brackets: ')', '}' or ']', f.e.:
#command A }\[C] => QOUT("A }[C]")
#command A }\[C] => QOut("A }[C]")
A }[C]
Will be perfectly translated. For me it seems to be limitation of
Clipper PP implementation (probably it's a side effect of some internal
@@ -292,7 +292,7 @@ making in last days.
illustrates it. Clipper does not preprocess the TR2.
#xtranslate TR1 [<x,...> D] => ! [#<x>] !
#xtranslate TR2 [<x,...> D] C => ! [#<x>] !
#xcommand CMD <*x*> => QOUT( #<x> )
#xcommand CMD <*x*> => QOut( #<x> )
proc main()
CMD $ TR1 a + b + c + d c
CMD $ TR2 a + b + c + d c
@@ -558,7 +558,7 @@ making in last days.
#define NEWCMD MYCMD
#xcommand CREATEDIRECTIVE => HASH_DIRECTIVE xcommand NEWCMD \<x> => ;;
QOUT( "INDIRECT # DIRECTIVE", #\<x> )
QOut( "INDIRECT # DIRECTIVE", #\<x> )
CREATEDIRECTIVE
MYCMD Hello
@@ -585,7 +585,7 @@ making in last days.
some other preprocessor rule, .f.e:
#define EOC ;;
#xcommand CREATECMD => #xcommand NEWCMD => QOUT("1") EOC QOUT("2")
#xcommand CREATECMD => #xcommand NEWCMD => QOut("1") EOC QOut("2")
CREATECMD
NEWCMD

2
harbour/doc/pragma.txt
View File

@@ -170,7 +170,7 @@ Syntax:
The above example is preprocessed into:
v:=[This is 'example' text with ''""[] embeded and C \nsequence]
qout(v)
QOut(v)
and at runtime the following is printed:

12
harbour/doc/todo.txt
View File

@@ -19,17 +19,17 @@ Status...: Working on it.
Assign to: <nobody>
Detail...: Add support for virtual file handles and registering some
meta handles so it will be possible to make:
h := fopen( "gzip:/tmp/myarchive.gz", FO_WRITE )
fwrite( h, cData )
fclose( h )
h := FOpen( "gzip:/tmp/myarchive.gz", FO_WRITE )
FWrite( h, cData )
FClose( h )
or:
h := fopen( "tcp:some.host:port", FO_WRITE )
h := FOpen( "tcp:some.host:port", FO_WRITE )
...
or:
h := fopen( "|lpr -PLaserJet", FO_WRITE )
h := FOpen( "|lpr -PLaserJet", FO_WRITE )
...
or:
h := fopen( "gunzip /tmp/myarchive.gz|", FO_READ )
h := FOpen( "gunzip /tmp/myarchive.gz|", FO_READ )
...
etc.
Status...: Open.

16
harbour/doc/tracing.txt
View File

@@ -167,32 +167,32 @@ query and set the trace level. From C code:
current state to a given value (which should be in the range [0,1],
otherwise the current state remains unchanged):
hb_tracestate(state);
hb_tracestate( state );
Therefore, to just query the current state, you can safely call
current_state = hb_tracestate(-1);
current_state = hb_tracestate( -1 );
To turn tracing completely off:
hb_tracestate(0);
hb_tracestate( 0 );
To turn tracing back on:
hb_tracestate(1);
hb_tracestate( 1 );
* To query the current tracing level, and optionally change the
current level to a given value (which should be in the range [0,5],
otherwise the current level remains unchanged):
hb_tracelevel(level);
hb_tracelevel( level );
Therefore, to just query the current level, you can safely call
current_level = hb_tracelevel(-1);
current_level = hb_tracelevel( -1 );
There are wrapper functions callable from Clipper code:
current_state := HB_TRACESTATE( [new_state] )
current_level := HB_TRACELEVEL( [new_level] )
current_state := hb_traceState( [new_state] )
current_level := hb_traceLevel( [new_level] )

2
harbour/doc/vm.txt
View File

@@ -283,7 +283,7 @@ Answer:
Harbour will not implement all of them as we want to provide the highest
freedom to programers to extend and modify Harbour as needed. In example:
Clipper language uses opcodes for: Row(), Col(), Upper(), Space(),
Replicate(), InKey(), Year(), Month(), etc... where we may just call a
Replicate(), Inkey(), Year(), Month(), etc... where we may just call a
standard C function, that uses the standard extend system and that may be
easily modified. So Harbour will use much less opcodes than the Clipper
language. This will also help to have a simpler and easier to maintain

2
harbour/doc/xhb-diff.txt
View File

@@ -2502,7 +2502,7 @@ and functions without 'v' which do not allow to access array items, i.e.:
int iValue = hb_parni( 2 );
These functions (without 'v') are also much more restrictive on accepted
parameters and do not make hidden parameter translations, i.e. hb_parl()
returns TRUE only for logical parameters and does not accept numeric
returns HB_TRUE only for logical parameters and does not accept numeric
values like hb_parvl() or _parl().
New functions without array index support were introduced to safely access
parameters without strict type checking. Such code: