               TUZFILTER V. 1.05 - free filtering on any DataSource 
               ====================================================


Hi, out there in the wilderness. Here may come a the solution for many of your
problems, related to filtering and indexing under DELPHI.

This little component implements a BDE-level filter, based on a callback into
your form's/unit's code, much like those QSort.-callback were.

The callback function does all the filtering stuff, ie. detemines, whether the
current record in scope is to be included or excluded, INDEPENDENTly of any
index-settings, data-links, 1:m table links or whatever and LIVE.

Installation:   after unpacking the ZIP-file, you'll find following files:

   -> FILTDEMO.*     a little demo-application
   -> FLTDEMO1.*     unit for FILTDEMO

   -> DBFILTUZ.INT   documentation (installation AND HOW TO USE)
   -> DBFILTUZ.DCU   TUZFilter VCL-component (see installation section in
                     DBFILTUZ.INT)
   -> DBFILTUZ.DCR   resource-file for DBFILTUZ.DCU


RUNNNING the example in FILTDEMO:

   following prerequisites have to be fullfilled to run FILTDEMO "out of the
   box":

   ->    A valid DBDEMOS-alias in you BDE-configuration (CUSTOMER.DB and
         ORDERS.DB will be accessed) must exist.
   ->    DBFILTUZ.DCU m,ust be installed to your COMPLIB.DCL (see installation
         section "how to install" in DBFILTUZ.INT)


FREEWARE:   This component is FREEWARE according to the terms in DISCLAIMER'S
            NOTE in DBFILTUZ.INT.
            Source can be obtained from author (see contact address at end of
            this file).


ADDITIONAL INFO, READ CAREFULLY:
================================

   I don't know, whether to state this as a "known bug" or not, but at least
   the following hint might be very helpful, bioth for security of code and
   for speed:

   DON'T CODE a "Application.ProcessMessages" line into your filterevent-handler

   Doing so, might confuse BDE which callback-events are "still to be processed"
   and which alredy are processed, leading into recursive calls of the filter-
   event handler until memory is low and BDE will GPF (IDAPI01.DLL 0003:xxxx or
   0001:xxxx).
   This GPFs might freeze WIN as well as throw backl the hard way onto DOS-prompt,
   leaving tables open, records locked and so on.




HISTORY of changes:
===================
VERSION 1.05:  hmmm, shoudl I call thisone a BUG-fix ? Well decide youself,
               here is what's happening why and how I worked around.
               Although V 1.04 worked very well and properly when PDX-tables
               were used, two users reported, that, when issuing a .LAST on a
               filtered dBASE-table (i.e. by a TDBNavigator-control), their
               programs threw an "at end of table exception", though neither
               the EOF-condition really was true, nor any erratic behavior
               took place, just that ugly nasty exception-box in front of your
               users'r eyes ....
               Richard Lebeda (tanks to him) provided me with a minimal sample,
               to reproduce that "feature", which _only_ occurs, if a BDE-
               callback filter ion dBASE-tables is aborted (which is done
               behind the screens, to get .FIRST/.LAST worling) and the table
               was set to it's last record. This IMHO is a bug in
               IDDBAS01.DLL, because aborting a callback-filter under no
               circumstances should result in a EOF or BOF condition and for
               sure it does not, when IDPDX01.DLL is used for PDX-tables.

               Well I can't rewrite the IDDBAS01.DLL but I found a workaround,
               which at least hides those ugly exceptions before the
               applications user's eyes.
               That workaround is done by temporarily catching exceptions,
               when a filter for dBASE-tables is up to be aborted (don't be
               concerned, the original exception-handler is restored immediatly
               after that EOF-exception has been catched).
               This avoids the EOF-exception trap, when your program is
               running in "real live", but it can't avoid that exception,
               under following circumstances:

               -> dBASE table is set to last record
               -> filter is active
               -> OPTIONS | ENVIRNMENNT "stop on exceptions" is set TRUE
               -> DELPHI's debugger is running

               for DELPHI's own exception-catcher (invooked by that "stop on
               exceptions" switch) will trap the exception, _before_ it
               reaches the "exception-killer" in TUZFilter. So, while
               designing/developing your program and matching the above
               conditions, yout might have to resume your program by F9/run-
               btn, when this exception will occur.

               Sorry, for beeing unable to provide you with a better solution,
               but, if I would prevent from aborting the filter when a .LAST
               move on dBASE-tables is issued, you won't see the last record,
               and I think a some of those nasty exception during development-
               cycleboxes are much better, than embezzling the last record.

               
               
VERSION 1.04:     BUG-fixes:
                  -> .LAST-method resulted in an empty result set/first record
                  -> adding a new record might result in an empty result set

   thanks to Frank Burle, who reported the bug on the .LAST-method on a
   dataset. This bug occurred when acting as follows:

      -> either use the mouse to drag the vertical slider thumb to it's lower
         end position (will result in an .LAST command on the dataset)
      -> or issue the .LAST command by keybord with crtl-end

   in both situations, V 1.03 returned an empty result set. This bug has been
   fixed and in addition some similar or related bugs has been fixed too:

      -> crtl-end or dragging the vert-thumb to the lower end on a DETAIL-
         table resulted in moving to the first instead of the last record in
         detail table (fixed)
      -> adding/inserting a new rceord into a filtered dataset may too have
         resulted in an empty resuult set under V 1.03 (fixed too, now works
         as expected)
         

VERSION 1.03:     BUG-fix, speed-improvement and initial default-setting

   bug-fix:   When using two master-datail linked tables like in the demo-form, and
   "quick-scrolling" thru the nmaster-tables by mouse (holding the down-arrow of
   the grid pressed), a "not enough memory-error" occurred, this should be fixed
   now (tnx to Peter Gentes, pointing me in rioght direction).
   Additionally, a similar bug lead to a GPF in IDAPI01.DLL, when a master-
   record with _no_ detail-recs was reached and the two tables additionally
   were liked by PdX' referential integrity, should be fixed too.

   speed-imporvement:   the detail-table isn't rebuild after every single
   record-skip in the master-table which (at least, when scrolling by
   keyboard) should improve scrolling speed.

   initial default setting:   I just added a default setting for all
   TUZFilter-properties when you draw a new component on your form.


VERSION 1.02:     correction in FLTDEMO1.PAS uses-clause

   so sorry, V 1.01 did include a typo. The uses-clause in FLTDEMO1 referenced
   a component DBFILTER (which was the original name of DBFILTUZ suring
   develpment, but has changed due to the fact, that I found another component
   already using that name). Unfortunatly, I just added the DBFiltUZ
   forgetting to delete the now obsolete old reference.
   In V 1.02 this has been changed, so compiles will no more break down with a
   "component not found" error for the obsolete refernce. That's the only
   change for V 1.02.


may the gods of the olymp smile on you ...

bye UZ/2       CIS: 100271,313

