ADir() Function

/*
ADIR()*

Fill a series of arrays with directory information
——————————————————————————
Syntax :

ADIR( [<cFilespec>],
      [<aFilenames>],
      [<aSizes>],
      [<aDates>],
      [<aTimes>],
      [<aAttributes>]) --> nFiles

Arguments :

<cFilespec> is the path specification of files to include in the scan of the DEFAULT directory. It is a standard file specification that can include the wildcard characters * and ?, as well as a drive and path reference. If omitted, the default specification is *.*.

<aFilenames> is the array to fill with the file names matching <cFilespec>. Each element contains the file name and extension as a character string in all uppercase letters.

<aSizes> is the array to fill with the sizes of the corresponding files in the <aFilenames> array. Each element is a numeric data type.

<aDates> is the array to fill with the dates of the corresponding files in the <aFilenames> array. Each element is a date data type.

<aTimes> is the array to fill with the times of the corresponding files in the <aFilenames> array. Each element filled contains a character string of the form: hh:mm:ss.

<aAttributes> is the array to fill with attributes of the corresponding files in the <aFilenames> array. Each element is a character string. If <aAttributes> is specified, hidden, system, and directory files are included as well as normal files. If <aAttributes> is not specified, only normal files are included.

Returns :

ADIR() returns the number of files matching the directory skeleton described in <cFilespec>.

Description :

ADIR() is an array function that performs two basic operations. First, it returns the number of files matching the file specification. Second, it fills a series of arrays with file names, sizes, dates, times, and attributes.

ADIR() is a compatibility function and therefore not recommended. It is superseded by the DIRECTORY() function which returns all file information in a multidimensional array.

Notes :

Directories: If you specify the <aAttributes> argument and <cFilespec> is *.*, directories will be included in <aFilenames>. In the <aAttributes> array, directories are indicated with an attribute value of “D”. If ADIR() is executed within a subdirectory, the first two entries of the <aFilenames> array are “.” and “..”, the parent and current directory aliases. The date and time of last update are reported for directories, but the size of a directory is always zero.

Examples :

This example creates an array to hold the names of all .txt files in the current DEFAULT directory, then uses AEVAL() to list them to the console:

 LOCAL aFiles[ADIR("*.TXT")]
 ADIR("*.TXT", aFiles)
 AEVAL(aFiles, { |element| QOUT(element) } )

Remarks :

ADIR() is an obsolete function with some drawbacks.

– Requires five separate arrays for each file specification : name, size, date, time and attrribute.

– Each of these array must be length of exact file count. Return value of function is number of files, so you need call this function twice : first for obtain number of files and second for actual file info.

– Including directories is depend of existence of <aAttributes>, and <aAttributes> require been length of exact file count.

So if you want to see directories you need call this function triple ( see below sample ).

As a result, as indicated in “Description” above, using DIRECTORY() instead of ADIR() may be more convenient.

*/

PROC Main()
LOCAL cFileSpec := "C:\hb32\*.*"
LOCAL aFileNames := ARRAY( ADIR( cFileSpec ) )
LOCAL nFileCount := LEN( aFileNames )
LOCAL aFileSizes := ARRAY( nFileCount ),;
      aFileDates := ARRAY( nFileCount ),;
      aFileTimes := ARRAY( nFileCount ),;
      aFileAttrb := ARRAY( nFileCount )
LOCAL nMaxFNmLen := 0
SET CENT ON
SET DATE GERM
nFileCount := ADIR( cFileSpec, aFileNames, aFileSizes,;
                    aFileDates, aFileTimes, aFileAttrb )
ASIZE( aFileNames, nFileCount )
ASIZE( aFileSizes, nFileCount )
ASIZE( aFileDates, nFileCount )
ASIZE( aFileTimes, nFileCount )
ASIZE( aFileAttrb, nFileCount )
ADIR( cFileSpec, aFileNames, aFileSizes, aFileDates,;
                 aFileTimes, aFileAttrb )
AEVAL( aFileNames, { | c1FName | nMaxFNmLen := ;
                      MAX( nMaxFNmLen, LEN( c1FName ) ) } )
AEVAL( aFileNames, { | c1FName, i1 | ;
                       QOUT( PADR( c1FName, nMaxFNmLen + 1 ),;
                       TRAN( aFileSizes[ i1 ], "999,999,999" ),;
                             aFileDates[ i1 ],;
                             aFileTimes[ i1 ],;
                             aFileAttrb[ i1] ) } )
?
WAIT "End of ADIR.prg"
RETU // ADir.Main()

/*

Result of ADIR.prg :
 .                   0  13.09.2012 02:07:15 D
 ..                  0  13.09.2012 02:07:15 D
 addons              0  13.09.2012 02:07:07 D
 bin                 0  13.09.2012 02:07:12 D
 ChangeLog   8,848,829  12.09.2012 01:59:44 A
 comp                0  13.09.2012 02:07:12 D
 contrib             0  13.09.2012 02:07:16 D
 COPYING        47,456  12.09.2012 01:59:44 A
 doc                 0  13.09.2012 02:07:07 D
 extras              0  13.09.2012 02:07:15 D
 include             0  13.09.2012 02:07:07 D
 INSTALL        79,968  12.09.2012 01:59:44 A
 lib                 0  13.09.2012 02:07:14 D
 NEWS          108,058  12.09.2012 01:59:44 A
 RELNOTES        9,832  18.04.2012 04:00:10 A
 tests               0  13.09.2012 02:07:15 D
 TODO            2,924  12.09.2012 01:59:44 A
 uninstall.exe 104,646  13.09.2012 02:07:12 A
End of ADIR.prg

*/

Memo File Extension

#include "dbinfo.ch"
PROC Main()
* Test .prg for MemoFExtn() function

 SetMode( 25, 80 ) 
 CLS
 ? "Memo File extension :", MemoFExtn() // NIL
 ? REPL( "-", 80 )

 cTfName := "MFInTst1"
 aStruct := { { "FLD1", "C", 10, 0 } }

 DBCREATE( cTfName, aStruct ) 
 USE ( cTfName )

 ? "Memo File extension :", ">" + MemoFExtn() + "<" // ><
 ? REPL( "-", 80 )

 cTfName := "MFInTst2"
 aStruct := { { "FLD1", "M", 10, 0 } }
 DBCREATE( cTfName, aStruct ) 
 USE ( cTfName )
 ? "Memo File extension :", MemoFExtn() // .dbt
 ? REPL( "-", 80 )

 cTfName := "MFInTst3"
 aStruct := { { "FLD1", "M", 10, 0 } }
 DBCREATE( cTfName, aStruct, "DBFFPT" ) 
 USE ( cTfName )
 ? "Memo File extension :", MemoFExtn() // .fpt
 ? REPL( "-", 80 )

 ?
 WAIT "EOF MemoFExtn.prg"

RETURN // MemoFExtn.Main()
/*
Function MemoFExtn() -> Memo File Extension of current table

 Return : If current work area is empty : NIL 
 elseIf current table not include MEMO field : ""
 else .dbt / or .fpt depending RDD used in creation of current table.

 Required :
 #include "dbinfo.ch"
Aug 2012

*/
FUNCTION MemoFExtn() // Memo file extension
LOCAL xRetVal

 IF !EMPTY( ALIAS() )
 IF DBINFO( DBI_MEMOHANDLE ) < 0
 xRetVal := ""
 ELSE 
 xRetVal := DBINFO( DBI_MEMOEXT ) 
 ENDIF 
 ENDIF !EMPTY( ALIAS() )

RETURN xRetVal // MemoFExtn()

File Terms

Binary File :

A file that contains an unformatted sequence of bytes. Carriage return, linefeed, or end of file characters have no special meaning in a binary file. Binary files include executable files, graphics files, or data files.

See Also: Text File

Delimited File :

A text file that contains variable-length database records with each record separated by a carriage return/linefeed pair ( CHR(13) + CHR(10) ) and terminated with an end of file mark ( CHR(26) ). Each field within a delimited file is variable length, not padded with either leading or trailing spaces, and separated by a comma. Character strings are optionally delimited to allow for embedded commas.

See Also: Database, SDF File, Text File

Directory :

The major operating system facility for cataloging files. A directory contains a list of files and references to child directories (subdirectories), and is identified by name. Directories can be nested forming a hierarchical tree structure. The operating system provides a number of facilities that allow users to create and delete directories.

See Also: Disk, File, Path, Volume

Drive :

A disk drive or a letter (normally followed by a colon) that designates a disk drive. On most computers, the letters A and B refer to floppy disk drives; other letters refer to fixed disk drives or logical drives (e.g., fixed disk partitions or network drives).

Extension :

A filename extension normally used for identifying the type or originating program of a file.

See Also: Drive, Filename, Path

File :

A file is an organized collection of bytes stored on disk, maintained by the operating system, and referenced by name. Its internal structure is solely determined by its creator.

See Also : Binary File, Database, Text File

File Handle :

An integer numeric value returned from FOPEN() or FCREATE() when a file is opened or created. This value is used to identify the file for other operations until it is closed.

Filename :

The name of a disk file that may optionally include a drive designator, path, and extension.

See Also: Drive, Extension, Path

Path :

A literal string that specifies the location of a disk directory in the tree structured directory system. A path specification consists of the following elements: an optional disk drive letter followed by a colon, an optional backslash indicating that the path starts at the root directory of the specified drive, the names of all the directories from the root directory to the target directory, separated by backslash () characters. Example: C:CLIPPERINCLUDE. A path list is a series of path specifications separated by semicolons.

SDF File :

A text file that contains fixed-length database records with each record separated by a carriage return/linefeed pair (CHR(13) + CHR(10)) and terminated with an end of file mark (CHR(26)). Each field within an SDF file is fixed-length with character strings padded with trailing spaces and numeric values padded with leading spaces. There are no field separators.

Separator :

The character or set of characters that differentiate fields or records from one another. In Clipper language, the DELIMITED and SDF file types have separators. The DELIMITED file uses a comma as the field separator and a carriage return/linefeed pair as the record separator. The SDF file type has no field separator, but also uses a carriage return/linefeed pair as the record separator.

See Also: Delimiter

Subdirectory :

See : Directory

Text File :

A file consisting entirely of ASCII characters. Each line is separated by a carriage return/linefeed pair (CHR(13) + CHR(10)) and the file is terminated with a end of file mark (CHR(26)).

See Also: Delimited File, Program File, SDF File

Volume :

A unit of disk storage uniquely identified by a label and of fixed size. A hard disk can be partitioned into one or more volumes by an operation system utility. Volumes are subdivided into one or more directories organized in tree structure.

See Also: Directory, Disk

Clipper Description

Developed by Nantucket software and released in winter of 1984, first shipping 25 May 1985.

Clipper was a typical database development language and DOS based. Originally is was used as a replacement programming language for Ashton Tate’s dbase II database environment that could be compiled and executed as a standalone application.

Millions of applications were built typically for businesses dealing with small databases like client management, stock keeping. Many applications for banking and insurance companies were developed were the application was considered too small to be developed and run on mainframes. Clipper often served as a front end exactly for the above mentioned mainframe applications and did very well in this area.

One of the language’s features: the possibility to link ‘C’ and machine language objects made it a virtual unlimited expandable environment. When you missed a feature, an interface or whatever you could program that yourself and the extension made a reusable part of your toolbox. Libraries were also made by third parties but the programmer could also create its own library or enhance the existing ones.

One of the disadvantages, for commercial developers at least, was that a clipper executable could easily be disassembled or de-compiled to produce native source code. There were even commercial packages for that. Between the manufacturers of decompilers and Clipper a covenant was agreed that with a certain code in the source the decompilers would not decompile. But for the hard core hackers no door was kept close.

Around the early 1990’s the users felt a need for a more object oriented environment. Nantucket’s answer was: Clipper 5.0 up to 5.3. This made the Clipper language more sophisticated, but completely OO it never was. Objects and classes could be created but the language needed more, and quickly, should it keep its programmers corps it had created since 1984.

Too late the Nantucket company realized it had to port the Clipper environment to the Windows platform as well and began developing a new project: Aspen: Clipper for Windows. Too late, or at least the research was not given top priority for research and development. In August 1994 (Shipped December 1995) a first version became available and was called: Clipper VO (virtual objects) It was truly windows based but had to cope with many typical first issue bugs that were not explained to the full extend. Again programmers had to build new work arounds and did not feel very comfortable with that idea.

The old stock of programmers however had already switched to Visual Basic (Microsoft) and later Delphi (Borland) This came about because many customers with small database environments wanted to upgrade to window versions in their turn pressured by their clients. And as usual clients wanted their applications yesterday!

A second reason why Clipper never got its previous user base back was that the transition to Clipper VO proved to be too complicated for many senior programmers, and juniors already learned to program in Delphi or VB and later Java.

That was a pity because VO proved to be a very powerful and sophisticated database development tool.

Though Nantucket / CA promised a high degree of compatibility with older developments this did not materialize to the degree to make life easier to former Clipper programmers. The result was that programs were rebuilt in the new environments, the best way to do porting actually. Again slimming down the market for Clipper programmers.

In 1995 Computer Associates bought up the Clipper environment, killed the Clipper DOS version and pre-matured project Aspen, and further developed VO

Other developments for Clipper:

Clipper also could be converted to run on UNIX systems by using a porting tool called Flagship. It runs suitably well.

XBase++ is an OO environment and translates DOS Clipper to Windows but does not enhance the clipper development to an event driven application.

Clip-4-Win is a 16 bit compiler and generated character based applications that ran fairly well within Windows.

Harbour  Clipper got a new life with the Harbour project.

The Harbour-project was started as an open source project in early 1999, the project is still on.

The Harbour programming language is a superset of the well known x-Base language, often referred to as Clipper. Harbour is 100% backward compatible with the Clipper Language, yet it adds many modern features and tools comparable to today’s leading compilers.

Out of the harbour-project, xHarbour (extended Harbour) was started late 2001 as a fork off of the Harbour Project

Clipper is still alive!

Chronology:

1984 first issue: Winter 1984

1990 first issue: Clipper 5.0 (distributed at DefCon fall 1990)

1994 first issue of Clipper VO

1997 Clipper VO 2.5

1999 An open source project: Harbour takes up the challenge

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note : This post gathered from here.