Listview mit Firemonkey

[Peter666]

Hi,

hat jemand eine Idee, wie ich mit TListview ~2500 Einträge schnell befüllen kann und die Bitmaps in dem jeweiligen TListviewItem nur zeichne sobald das nötig ist? So wie ich das gesehen habe gibt es keine Cachefunktion, so dass im schlimmsten Fall für die 2500 Einträge 128x128 Pixel pro Bitmap der Speicher des Mobilgerätes schnell voll ist.

Peter

[Luckie]

2500 Eintrage? Da scrollt man sich ja zu Tode, wenn man was sucht.

[Harry Stahl]

Also normalerweise erstellt FMX die Objekte erst dann, wenn sie angezeigt werden sollen und verwirft sie wieder, wenn sie außer Sicht sind. So ist das zumindest beim Grid, aber ich gehe davon aus, dass es bei der Listview entsprechend ist. Teste es doch einfach einmal aus.

[Sir Rufo]

Zitat von Harry Stahl:

Also normalerweise erstellt FMX die Objekte erst dann, wenn sie angezeigt werden sollen und verwirft sie wieder, wenn sie außer Sicht sind. So ist das zumindest beim Grid, aber ich gehe davon aus, dass es bei der Listview entsprechend ist. Teste es doch einfach einmal aus.

Nein, ist nicht so, die ListView (FMX) greift sofort alles ab.

[Harry Stahl]

Dann bliebe evtl.noch die Option, die Bitmap nicht für die einzelnen Listview-Items zu erzeugen, sondern nur im Onpaint-Event zu zeichnen. Wenn ich das richtig in Erinnerung habe, gibt es aber kein Paint-Event für die einzelnen List-Items, man müsste also selber berechnen, welche Listview-Items gerade sichtbar wären und wo was beim OnPaint-Event der Listview zu zeichnen wäre.

Leider muss ich im Moment mit einer konkreten Lösung dafür passen...

[Harry Stahl]

Oder: man erzeugt z.B., erst mal die ersten 20 Bitmaps für die ersten ListViewItems. Dann reagiert man auf das ändern des aktuellen Indexes und erzeugt eine entsprechende Anzahl von Bitmaps für die ListViewItems davor und dahinter (soweit noch nicht vorhanden).

Das ist eine gängige Technik, wie man das z.B. beim Rendern von PDF-Seiten anwendet.

[himitsu]

Zitat von Luckie:

2500 Eintrage? Da scrollt man sich ja zu Tode, wenn man was sucht.

UND jeder Eintrag ist auch noch mindestens 130 Pixel hoch ... 325.000 Pixel (300 bis 600 Bildschirme lang)

Ein Grid/Liste mit Filterfunktion wäre da fast schon angebracht.

[Luckie]

Zitat von himitsu:

Zitat von Luckie:

2500 Eintrage? Da scrollt man sich ja zu Tode, wenn man was sucht.

UND jeder Eintrag ist auch noch mindestens 130 Pixel hoch ... 325.000 Pixel (300 bis 600 Bildschirme lang)

Ein Grid/Liste mit Filterfunktion wäre da fast schon angebracht.

Ich stelle mir das ganze gerade auf einem Smartphone vor.

[Sir Rufo]

Grundsätzlich stellt das kein Problem dar wenn man sich so bekannte Shopping-Apps von amazon oder ebay anschaut. Bislang habe ich dort keine Probleme gehabt auch mit riesigen Trefferlisten.

(Nein, gerade eine Trefferliste mit 1250 Einträge angeschaut - kein Problem und langsam ist es auch nicht)
(Und noch eine mit >13000 Einträgen machte auch keine Probleme)

[bernau]

Zitat von Luckie:

2500 Eintrage? Da scrollt man sich ja zu Tode, wenn man was sucht.

Immer diese Fragen nach dem Sinn oder Unsinn. ( Die Kritik gilt nicht nur für dich, Luckie.)

Die Frage war ja nicht, ob es sinnvoll ist 2500 zu verwenden, sondern eine andere.

Wir kennen den Kontext nicht. Und ja, manchmal ist es einfacher in einer großen Liste mit scrollen etwas zu suchen, als vorher einen Filter einzugeben.