On Fri, 25 Apr 2008, Szakáts Viktor wrote:
Hi Przemek,
In real world test it looks good after this modification.
I'm attaching a small test program which traces the way
callbacks are called and status (:rowPos, RecNo()) changes.
The output looks much different from Clipper. (Being exactly
Clipper compatible on this level is certainly a plus, but
maybe isn't worth the extra effort.)
Thank you very much, I'll make test in a weekend.
BTW which Clipper version did you use for tests?
I know about some small differences to CL52 but the general
rules are very similar. CL53 TBrowse is a different story.
I used 5.2 for this comparison.

I've now tried with 5.3 which behaves differently
in a few places, but overall I cannot easily see
improvements over 5.2, at least not in these tests.

All forward skips inside for cursor movements (not the skips
for update) are replicate twice. Such effect can be easy
reached in :setPosition() by moving back to previous position
or top row. Unlike the problem with record refreshing
I described few days ago it looks for me like a protection
to detect network updates. It was probably necessary
because Clipper does not properly respect value returned
from skip block during buffer updating (:readRecord() and
:stabilize()). But it's also quite expensive for strongly
filtered tables. Without bitmap filters it's real performance
killer. Instead of replicating it I'd prefer to add full
support for values returned from skip block in all places
with automatic buffer updating and scrolling just like it
is done in :setPosition() now. It means that user skip code
blocks will fully control the TBrowse behavior. From the
user point of view in Clipper some states are undefined.
Yes, that's right. I'd also rather concentrate on replicating
the _documented_ behavior (which look pretty complete now)
and to avoid those performance problems you describe. Filtered
tables can indeed kill a TB.

Brgds,
Viktor

_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour

Reply via email to