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 Bäurle, 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