IMHO, the ugliest thing in HMG is the Browse control, but before blame me, please, let me say that this is not (mostly) my fault

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!

Amazing Roberto. Do you still have only 24 hours a day? I doubt.

Wonderful

Thanks a lot maestro

Best Regards

--

Esgici

I always find spare time to do funny things

And an important thing for people (like you and me) working with remote data is the 'grid.24' sample.

You have now full control over virtual Grid, so you can edit and add when/valid procedures, so to deal with remote data, you only need to give to virtual grid the needed info in the 'OnQueryData' procedure.

Please, give it a try...

Thanks!

And...

Please test and report any problem you found!

Or local data coming from (ie) SqLite.

Unfortunately I can't compile the samples.

This is the error log.

Windows XP SP3 HMG Test XIII Grid25 no problems

Very very AMAZING master.

Thanks a lot.

My best regards,