home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD1.mdf / pascal / library / dos / btree / btriev14 / history.txt < prev    next >
Encoding:
Text File  |  1991-10-27  |  5.3 KB  |  92 lines
  1. {HISTORY of BTP - the Btrieve Unit for Turbo Pascal 6.0     V1.4, 10/27/91  }
  2. (* ----------------------------------------------------------------------- *)
  3. Version 1.0   4/9/91: Initial functioning unit, released 9/5/91.
  4.  
  5. Version 1.1   9/8/91: Corrected a problem occuring in Btrieve files that had
  6.                       segmented keys with more than one segment.  The stats
  7.    stored by the BFile.Init constructor were not calculating the number of
  8.    segments properly.  The CreateFile function was also modified to deal with
  9.    the same key problem.  This change forces one more statement to be placed
  10.    in any 'create file' routine.  Any of the 24 key arrays not used in a file
  11.    must have their key flags set to zero.  See Create.PAS for an example.
  12.  
  13. Version 1.2  9/16/91: NOT RELEASED PUBLICLY.
  14.                       Derived a new base object, BRecMgr, from what HAD been
  15.    my base object, BFile.  It made sense to me to provide access directly
  16.    thru an object to the basic, non-file, non-record oriented Btrieve
  17.    operations: Begin/End/Abort Transaction, Version, Stop and Reset.  This
  18.    BLOWS compatibility with any code you wrote under prior versions of this
  19.    unit as the BT function is now virtual.  You should NOT call the ancestor
  20.    BT function in your override...replace it completely as shown in the
  21.    example programs and in BTP.DOC.
  22.  
  23.    BRecMgr has a variant record field to hold info on the version of Btrieve
  24.    the user is running.  That data is set by BRecMgr.Init.
  25.  
  26. Version 1.3 10/11/91: Unit name changed to BTP.  Bug fixed that would give
  27.                       incorrect result in BFile.NumRecs if number of records
  28.    exceeded 32,767.  Made a number of "touch-up" changes to make it easier to
  29.    use dynamic variables of the various data types in BTP.  Note particularly
  30.    that the CreateFile function now requires a second parameter, a pointer to
  31.    a Btrieve file spec as defined in BTP.
  32.  
  33.    The constructors for BRecMgr and BFile now set up a string data field,
  34.    VersionString, equal to the version number of Btrieve running in the user's
  35.    computer.  This is in addition to establishing the record field Version,
  36.    which contains the exact bytes returned by the Btrieve version call.
  37.  
  38.    All example programs were modified to reflect the changes in 1.2 and 1.3.
  39.  
  40. Version 1.4 10/27/91: Nomenclature of data types improved and made more
  41.                       consistent, both within BTP and with TP6's own internal
  42.    Turbo Vision style.  TRecMgr and BFile are now separate "base" objects.
  43.    Added BFixed and BFileExt objects, both descendants of BFile.  Together
  44.    these permit handling any standard fixed-length file, and provide complete
  45.    support for the "read" extended calls (the get and step extended calls),
  46.    including handling of all the drudgery of constructing data buffers.  This
  47.    was no small task!  For extended calls, you need simply insert your filter
  48.    and extractor specs into the provided collections in BFileExt.  The rest
  49.    is handled internally by the object's internal methods and your standard
  50.    override of the BTExt function.
  51.  
  52.    An object of type BFileExt can freely entertain both standard BT and
  53.    extended BTExt calls thanks to encapsulation of the position block in the
  54.    object (see EXAMPLE2.PAS).  However, I recommend use of BFileExt only if
  55.    you are truly going to use extended calls for a particular file.  This is
  56.    because there is about 32K more overhead per BFileExt object than in BFile.
  57.    The size of a BFile object is 698 bytes.  The size of a BFileExt object is
  58.    722 bytes, plus the size of the extended data buffer, which I default to
  59.    32767 bytes, plus the size of any items inserted into the two collections.
  60.    Note that the size of a BFixed object is 5043 bytes, to hold room for a
  61.    buffer equal to the maximum size of a fixed length record, and the maximum
  62.    length of a key.
  63.  
  64.    BFile and its descendants now take an Open mode parameter.
  65.  
  66.    The BFile.BT virtual function is now Abstract, to assure you don't call
  67.    it without overriding it.
  68.  
  69.    The BFileExt.BTExt method must be overridden, with the override calling
  70.    the ancestor; i.e. your override must be of a standard form, and must call
  71.    BFileExt.BTExt.  This is because BFileExt.BTExt is what sets the buffer
  72.    length and constructs the buffer for extended read calls.  This is in
  73.    contrast to BFile.BT or BFileExt.BT, which must be overridden by REPLACING
  74.    them, as shown in the example programs and in BTP.DOC.
  75.  
  76.    BFileExt's data fields include two collections.  The FilterSpec collection
  77.    need not hold any objects, but the ExtractorSpec must always hold at least
  78.    one.  Now, for extended calls, you handle these data fields as follows
  79.    (see EXAMPLE2.PAS):
  80.    1:  HEADER is handled internally.  Don't mess with it.
  81.    2:  FILTER's fields are assigned by your program.
  82.    3:  FILTERSPEC collection may or may not hold any objects, depending on
  83.        your program's needs.
  84.    4:  EXTRACTOR must be initialized.
  85.    5:  EXTRACTORSPEC collection must hold at least one object.
  86.    6:  EXTDBUFFER is handled internally.  Don't mess with it, except to
  87.        use it as shown in EXAMPLE2.PAS when you override BFileExt.BTExt.
  88.  
  89.  
  90.    BTP 1.4 IS THE FIRST *SHAREWARE* RELEASE.  The BTP product is no longer
  91.    FreeWare.
  92.