[Lazarus] In search of a component for holding a table of strings

[Jürgen Hestermann]

Am 2017-01-10 um 13:35 schrieb Graeme Geldenhuys via Lazarus:
 >> I can also apply some more sophisticated functions like attribute change, delete, rename, etc.
 >> where I would not like to be resticted on the number of files in any way.
 > You don't need to see those items to apply those attributes.

I prefer to see the items before I change them instead of blindly relying on a filter.
A filter may include items I did not want to (filters can get complex).
I need the abillity to have at least a quick glance over the list before I do the changes.


 >> Filtering: Yes. But it's not always the first step!
 > So pulling in 50+ million records into a data grid over a internet
 > connection (or worse, a dial-up connection) simply for the sake of it,
 > then only filtering down the data.... all seems very inefficient.

Why pulling records over an internet connection?
In this case the list needs to be hold on the server and the client just
loads the next page if you scroll.
But as said: There are use cases where you may want to start with a filter
and there are others where it is not.
Just let the user decide and do not force him to do it one way only.


 > Put another way, lets populate a dropdown combobox with 50 million items
 > and set the item display limit to 15 items. So if you open that, and
 > move the scrollbar with the mouse only 1 pixel, you'll probably scroll
 > the items by 100,000. Absolute pointless behaviour and design.

I don't understand your example.
When a subset of 15 items is displayed and you scroll down
then only the next subset (again 15 items) needs to be displayed.
Where is the problem?
And when the slider is too sensitive for the large list then don't use it!
Instead provide other ways to jump to specific entries.
If I have a file list sorted by date I may jump to a specific date and then
have the abilitiy to scroll around this date with the cursor keys or page up/down keys.
Where is the problem?


 > I cannot see a single use case where that will be a good idea.

I mentioned the case of the file manager.
Just look at Xtree/Ztree.
The concept exists since decades and I am missing it in many other applications.


 > If you have the time, read the book "About Face 3: The Essentials of
 > Interaction Design". You might learn something.

These books are just opinions of other people.
Nice to reed to get some ideas but they will never
have the overall solution for all user interfaces.


BTW: In the end there is not much difference between filtering and showing a flat list.
You will never see all entries side by side in one window.
In both cases a subset is displayed.

When showing all entries you only see the first n records that fit on the window.
After scrolling down, the next n records are shown.
When jumping somewhere, still only n records need to be retrieved and shown.
I don't see the problem with this.
It's just like applying a new filter with each scroll event.

When using a filter as the first step you get a list of all matching entries.
But this list can get large too. You do not know before.
Then you end up with the same problem:
A large list of entries that needs to be displayed to the user.