I'll explain that:
Back in time to early 2002, I've researched about a Windows native control that could be a good host for a Browse, so, I've decided that such control should be ListView.
Very soon realized that filling it with the 'additem' method (calling as many times as rows in the table) could work for small-sized ones only, so, I've discovered the 'virtual ListView'.
The virtual ListView must not be filled in the usual way. It automatically calls an user-specified procedure (a 'callback' procedure) each time that it must draw a cell in the screen.
Such procedure receives the cell's row and column. The user must return the adequate content for that cell.
So, theoretically, you could handle billion records tables without any noticeable speed overhead.
You only should go to the required row and retrieve the data.
It worked fine for non indexed tables using dbGoto() function and was really fast.
The problem was that for making indexed tables to work in this scheme, I've needed the OrdKeyGoTo()/OrdKeyNo() functions, but by 2002 these functions were not implemented in Harbour.
Finally I've 'solved' the problem using a standard ListView containing only 'visible' records and implementing a terribly complex trickery to pretend that it was the real thing.
I've never abandoned my original idea and attempted again many years later, when the OrdKeyGoTo() and OrdKeyNo() were finally implemented, but they were very very slow,
making again impossible to use (I've attempted complex cache schemes to speed up the process with no results).
Now, I've decided to try again and guess what...?
It works smoothly and quickly now!!!
My original idea was that we should have only one table style control to handle arrays, dbf files and random data. That control should be the Grid, so I've done
The code attached to this message should be considered as 'pre-alpha'.
This means that it could be unstable, unreliable and (more important) that the sources are really ugly and dirty
So, this is not 'Test XIV' yet, this is only some thoughts in the form of code.
The final idea (if this finally works and get all browse powers) is to fully replace browse.
Is all this thing redundant, considering that Browse already is there?
The current Browse should be kept for backwards compatibility only, in the form of a wrapper for a data grid, and completely eliminated from documentation, so, at the end, will not be redundancy.
Enjoy!- HMG 3.0.0 (Forum Test ???) Changelog:
English:
--------
- New: Virtual Grid supports allowedit, ColumnWhen, ColumnValid
DynamicBackColor, DynamicForeColor and ColumnControls properties now.
Sample: GRID_24.
- New: Grid supports the following new things:
- 'RecordSource' Property.
- 'ColumnFields' Property.
- 'AllowAppend' Property.
- 'Buffered' Property.
- 'RecNo' Property.
- 'Append' Method.
- 'Save' Method.
- 'Refresh' Method.
These new elements are meant to give to grid, support for dbf
tables handling.
In 'Buffered' mode, adding a record, store it in a temporary
(1 record buffer). This buffer is flushed when you add another
record, with the 'Save' method or when the grid control is
released. The main advabtage of this way is that the new record
goes to the end of the grid, not being affected by current
index order (it will be ordered when saved).
'Append' has the Alt+A shortcut.
'Save' has the Alt+S shotcut.
You can set currently selected item with the 'Value'
property, as in a standard 'CellNavigation' style grid.
Alternatively you can use 'RecNo' property to set selected
item with physical record number.
'Refresh' method is meant to update changes made outside from
grid.
Is this redundant, duplicating Browse functionality?: No!
Please, read the 'Something funny happened in the way to
the browse' article in HMG Forum (http://www.hmgforum.com) for a
detailed explanation.
Sample: GRID_25.
HMG Test XIII 
