I'm using the excellent Virtual Treeview (VST) control in my project and
as you may or may not know, it has the ability to initialize tree nodes
on demand, i.e. only when they become visible for example.

This mechanism lends itself very well to displaying large amounts of
database data as the user interface stays responsive because only a
small amount of data has to be access at any one time.

As the initialization of a node does not happen in a linear fashion, I
was going to use RecNo to position the row cursor of the dataset at the
required location (VST returns the relative index of a node when
OnInitNode gets called).  Unfortunately, with elevateDB the RecNo value
is only useful if there is no active range being applied to the table.

My question: is there an alternate way of accomplishing the same thing?

Basically, I know the number of rows the dataset has after applying the
range, and I have the row number I need the data for - how can I
position the row pointer in the most efficient manner?

I already tried using MoveBy, but that gets progressively slower the
larger the value for MoveBy becomes...

Any and all suggestions welcome.


Ulrich

Ulrich

Use BookMarks. The only difference you have to take care is about free them
after using it and not change the current index between the calls to
GetBookMark and GotoBookMark.

Insead of using:
var nRec: Integer;
begin
       nRec := Table.Recno;
       // Do something
       Table.Recno := nRec;
end;

use
var B: TBookMark;
begin
       B := Table.GetBookMark;
       try
           // Do something
           Table.GotoBookMark(B);
       finally
           Table.FreeBookMark(B);   <--- Even if you don´t use
GotoBookMark, you must free it.
       end;
end;

Eduardo

Ulrich,

<< My question: is there an alternate way of accomplishing the same thing?
>>

Eduardo is correct - bookmarks are the way to go.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Eduardo is correct - bookmarks are the way to go.

I'm a bit slow today, so you'll have to help me out a bit: I don't quite
follow how I would have to use bookmarks in my case.

I'm not trying to get back to a row I've been before... unless I can
"make" my own bookmark and use it to move the row pointer?  If that's
possible, is the bookmark just an index in the current dataset?

Ulrich

Hello Tim,

> << My question: is there an alternate way of accomplishing the same thing?
>  >>
>
> Eduardo is correct - bookmarks are the way to go.

Does this give us a full state scrollbars on grids ?
If yes, why not implement it into EDB ?

Thank you

--
Charalabos Michael - [Creation Power] - http://www.creationpower.gr

Eduardo

The way I'm reading his post is if someone clicks on the VST say to expand a node then he uses the index number of the item they've clicked on, and the branches, to retrieve the appropriate record.

So if someone clicked on the third item with DBISAM it was a simple matter to go Table.Recno := vst.index and woosh. Now he's trying to use MoveBy and neither DBISAM nor ElevateDB have a fast MoveBy (I think all they do is a series of Next's or Prior's). This is fine if you have a small table / range but when it gets to a few hundred woops.

So good try but I don't think bookmarks will work. Storing a bookmark as part of the node data would be a great way to return quickly though, but I can never remember what invalidates a bookmark.

The other part of the problem is you can't just use an index because it wouldn't be in sequence.


Roy Lambert

Roy

I understand your point but bookmarks are really a good solution to replace
Recno. Perhaps sometimes it will not be a good replacement.

Eduardo

Michael,

<< Does this give us a full state scrollbars on grids ? >>

No, it's a different issue altogether.

--
Tim Young
Elevate Software
www.elevatesoft.com

Ulrich,

<< I'm not trying to get back to a row I've been before... unless I can
"make" my own bookmark and use it to move the row pointer?  If that's
possible, is the bookmark just an index in the current dataset? >>

How many possible rows are in each level under a given node ?  As long as
we're not talking hundreds of thousands, then you can load the bookmarks for
each node's children as they are expanded.  I'm not saying that this will
mesh with the way that your virtual treeview works - I'm just saying that
this is the only way to do a virtual treeview efficiently.  Building a
treeview on the relative position of the items in the dataset is not an
efficient way to handle such a requirement.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< So if someone clicked on the third item with DBISAM it was a simple
matter to go Table.Recno := vst.index and woosh. Now he's trying to use
MoveBy and neither DBISAM nor ElevateDB have a fast MoveBy (I think all they
do is a series of Next's or Prior's). This is fine if you have a small table
/ range but when it gets to a few hundred woops. >>

MoveBy is not controlled by us, so there's nothing we can do about the way
it is implemented.  However, a few hundred rows is no problem - you'd have
to get into the tens of thousands before you'd see any noticeable slowdown,
unless you're talking a remote session over a very slow connection.

<< So good try but I don't think bookmarks will work. Storing a bookmark as
part of the node data would be a great way to return quickly though, but I
can never remember what invalidates a bookmark. >>

It doesn't matter whether the bookmark is valid or not, it will still put
you on the closest match, and that's all that matters when you're talking
about navigation on a table or sensitive result set.  Other sessions are
possibly changing the data underneath, so what you see at any given moment
is only a snapshot in time.

<< The other part of the problem is you can't just use an index because it
wouldn't be in sequence. >>

Bookmarks work in EDB regardless of whether the table has an index, or what
order the index is in.  And all indexes in EDB are ordered by their
insertion order if they are not unique.  For example, if you had an index on
State in a table, and you have lots of 'NY' rows, then all of the 'NY' rows
would be ordered by the State first, and by the insertion order second.

--
Tim Young
Elevate Software
www.elevatesoft.com