TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Rund um die LCL und andere Komponenten
TBug
Beiträge: 177
Registriert: Mi 2. Sep 2015, 11:09
OS, Lazarus, FPC: Lazaurus 2.2.4 FPC 3.2.2
CPU-Target: Windows 32/64bit

TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von TBug »

Hallo zusammen,

beide Komponenten bieten im Prinzip das, was man für die Darstellung einer Liste benötigt (bei TListView der ViewStyle vsReport).

Allerdings benötige ich die Komponenten mit folgenden Vorraussetzungen.

- 1. es müssen Objekte eingebunden werden
- 2. die Spalten müssen in der Größe änderbar sein
- 3. es gibt "nicht sichtbare" Spalten, welche unsichtbar bleiben sollen
- 4. die Spalten müssen per Mausclick sortiert werden können
- 5. sichtbare Spalten müssen verschiebbar sein
- 6. AutoSizing der Spalten beim Doppelklick

Kennt jemand eine solche Komponente, welche im Gegensatz zu TStringList oder TListView funktional und visuell keine Einschränkungen haben?

Für jeden Hinweis bin ich sehr dankbar.
.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von wp_xyz »

Hast du dich jemals ernsthaft mit TStringGrid befasst? (https://wiki.lazarus.freepascal.org/Gri ... rence_Page).
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
1. es müssen Objekte eingebunden werden
Hier weiß ich nicht, was du meinst (Objekte pro Zelle, pro Zeile, pro Spalte? Objekte statt Text)? Aber vielleicht reicht die Information, dass es neben der Eigenschaft Cells[Col, Row] auch eine Eigenschaft Objects[Col, Row] gibt. Das habe ich allerdings noch nie ausprobiert.
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 2. die Spalten müssen in der Größe änderbar sein
Aktiviere die Option goColSizing. Um auch die Breite der festen Spalte verändern zu können, muss zusätzlich die Option goFixedColSizing aktiv sein.
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 3. es gibt "nicht sichtbare" Spalten, welche unsichtbar bleiben sollen
Benutze den Spalteneditor ('...' neben der Eigenschaft "Columns"), um die Spalten als TGridColumn-Klassen hinzuzufügen. Nach Anklicken einer Spalte im Objektbaum kannst du die Eigenschaft "Visible" für die unsichtbaren Spalten auf false setzen.
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 4. die Spalten müssen per Mausclick sortiert werden können
Aktiviere die Eigenschaft "ColumClickSorts". Der Klick muss auf dem Spaltenkopf erfolgen. Eine sortierte Spalte wird mit einem Sortierpfeil gekennzeichnet. Ein zweiter Klick dreht die Sortierrichtung um. Rücknahme der Sortierung z.B. bei einem dritten Klick geht nicht, möglicherweise aber mit eigenem Code - das StringGrid ist sehr flexibel.
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 5. sichtbare Spalten müssen verschiebbar sein
Aktiviere die Option goColMoving. Klicke in der Kopfzelle, halte die Maustaste gedrückt und schiebe die Spalte an die neue Position. Eine rote dicke Linie zeigt die neue Einfügeposition an. Wenn dir das Rot nicht gefällt, ändere die Eigenschaft ColRowDragIndicatorColor
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 6. AutoSizing der Spalten beim Doppelklick
Aktiviere die Option goDblClickAutoSize. Der Doppelklick muss auf der Trennlinie zwischen zwei Spalten erfolgen (ist etwas schwer zu treffen) und betrifft die Spalte vor der Trennlinie.

Probier das beigefügte Test-Projekt aus. Also wo ist hier Pest und Cholera?
Dateianhänge
TBug.zip
(1.99 KiB) 65-mal heruntergeladen
Zuletzt geändert von wp_xyz am Do 19. Mai 2022, 00:33, insgesamt 1-mal geändert.

Benutzeravatar
Winni
Beiträge: 1577
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.2.2, fpc 3.2.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von Winni »

Hi!

Um eine Spalte temporär unsichtbar zu machen geht auch dieser Trick;

Code: Alles auswählen

StringGrid1.Columns[k].Width:= 0;   
Wenn man die Spalte wieder sehen möchte, weist man wieder die passende Breite zu,

Pest und Colera sind da nirgends sichtbar.
Man muss sich nur mit den Möglichkeiten der Componente beschäftigen.

Aber das hat wp_xyz ja schon gezeigt.

Winni

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von wp_xyz »

Winni hat geschrieben:
Do 19. Mai 2022, 00:14
Um eine Spalte temporär unsichtbar zu machen geht auch dieser Trick;

Code: Alles auswählen

StringGrid1.Columns[k].Width:= 0;   
Das Problem ist dabei, dass man bei aktivem ColSizing die verborgene Spalte mit der Maus wieder aufziehen kann. Auch kann mit etwas Ungeschick die verborgene Spalte beim Doppelklick auf der Spaltentrennlinie neben ihr wieder sichtbar werden, weil sie ihre Breite entsprechend dem Inhalt anpasst.

Also, wenn man eh mit Columns arbeitet, ist Grid.Columns[k].Visible := false eindeutig sicherer. Ohne Columns kann man Grid.ColWidths[k] auf 0 setzen, darf aber das ColSizing und den Doppelklick in den Options nicht zulassen, evtl auch nicht das ColMoving.

Benutzeravatar
Winni
Beiträge: 1577
Registriert: Mo 2. Mär 2009, 16:45
OS, Lazarus, FPC: Laz2.2.2, fpc 3.2.2
CPU-Target: 64Bit
Wohnort: Fast Dänemark

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von Winni »

wp_xyz hat geschrieben:
Do 19. Mai 2022, 00:29

Das Problem ist dabei, dass man bei aktivem ColSizing die verborgene Spalte mit der Maus wieder aufziehen kann. Auch kann mit etwas Ungeschick die verborgene Spalte beim Doppelklick auf der Spaltentrennlinie neben ihr wieder sichtbar werden, weil sie ihre Breite entsprechend dem Inhalt anpasst.

Also, wenn man eh mit Columns arbeitet, ist Grid.Columns[k].Visible := false eindeutig sicherer. Ohne Columns kann man Grid.ColWidths[k] auf 0 setzen, darf aber das ColSizing und den Doppelklick in den Options nicht zulassen, evtl auch nicht das ColMoving.

Hi!

Das stimmt nicht.

Wenn width := 0 dann hat die Spalte die Breite Null (sic) und damit auch keine Trennlinie, an der sich eine ungeschickte Maus aufhängen könnte.

Sei doch nicht so verbohrt.

Winni

PascalDragon
Beiträge: 825
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von PascalDragon »

Winni hat geschrieben:
Do 19. Mai 2022, 01:12
Das stimmt nicht.
Kann ich auch: Das stimmt nicht.
Winni hat geschrieben:
Do 19. Mai 2022, 01:12
Wenn width := 0 dann hat die Spalte die Breite Null (sic) und damit auch keine Trennlinie, an der sich eine ungeschickte Maus aufhängen könnte.
Schneller Test: StringGrid auf eine Form geknallt, mittels StringGrid1.Cells den Spalten in Zeile 0 nen Namen verpasst, coColSizing aktiviert und mit StringGrid1.ColWidths die Breite von Spalte 3 (von 5) auf 0 gesetzt (Columns kann nur genutzt werden, wenn auch wirklich Spalten angelegt wurden). Und siehe da: wenn ich zwischen den Spalten 2 und 4 aufziehe, so erscheint die Spalte 3 wieder. Sowas aber auch...
Es verhält sich übrigens genau gleich, wenn man Columns nutzt.
Winni hat geschrieben:
Do 19. Mai 2022, 01:12
Sei doch nicht so verbohrt.
Teste doch vielleicht mal vorher, bevor du Leuten unterstellst verbohrt zu sein.
FPC Compiler Entwickler

BeniBela
Beiträge: 308
Registriert: Sa 21. Mär 2009, 17:31
OS, Lazarus, FPC: Linux (Lazarus SVN, FPC 2.4)
CPU-Target: 64 Bit

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von BeniBela »

Mein TreeListView kann das alles: https://benibela.de/components_en.html#treelistview
TBug hat geschrieben:
Mi 18. Mai 2022, 22:27
- 6. AutoSizing der Spalten beim Doppelklick
Bei Doppelklick auf den Spaltenseparator

TBug
Beiträge: 177
Registriert: Mi 2. Sep 2015, 11:09
OS, Lazarus, FPC: Lazaurus 2.2.4 FPC 3.2.2
CPU-Target: Windows 32/64bit

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von TBug »

Hallo zusammen,

ich glaube hier gab es ein kleines Missverständnis.
Lag wahrscheinlich an der Aufzählung.

Ich habe mich sehr intensiv mit beiden Komponenten auseinandergesetzt, wahrscheinlich eher zu viel,als zu wenig.

TStringGrid kann natürlich sehr viel und TListView natürlich auch und wie ich wo was einzustellen habe ist mir durchaus bewußt und habe im ersten Post ja bereits geschrieben, dass die Komponenten ja eigentlich im Groben schon das beinhalten was man benötigt.

Die Aufzählung war nur dafür gedacht, einen Hinweis zu erhalten, falls jemand eine gleichgeartete Komponente kennt, die eben alle diese Möglichkeiten besitzt und auch funktioniert.


Pest und Cholera bezieht sich auf die Darstellung und Funktionalität der Header beider Komponenten.

Ich habe "wp_xyz"s Beispiel ein wenig erweitert, damit man sehen kann, dass die StringGrid-Komponente an manchen Stellen an ihre Grenzen stößt.

So sieht man im zweiten Grid, welches keine Einträge hat, dass man zwar den Header anklicken kann, die Änderungen der Sortierreihenfolge aber erst sichtbar wird, wenn der Header neu gezeichnet werden muss, zum Beipiel durch Erweitern der Zelle. Auch schön zu sehen ist, dass die Scrollbalken beim Erweitern von Zellen nicht automatisch angezeigt werden. Ignoriert werden auch die Min- und Max-Angaben zur Spaltenbreite. Trotz aktivierter goDblClickAutoSize-Option ändert sich die Spaltenbreite nicht. (eigentlich schon, aber nicht so wie bei TListView, also wechselweise zwischen Headertext-Größe und Inhaltsbreite)
Ein weiteres Manko der header ist, dass wenn die Spaltenbreite so breit wie der Text ist und dann die Sortierung durch anklicken aktiviert wird, der Text nicht mehr ganz dargestellt wird.

Bei der TListView-Komponente funktionieren hingenen das Doppelklicken und das Anzeigen der Sortierreihenfolge. Dafür sich andere Issues vorhanden, denn auch TListView ignoriert Min und Max. Noch viel schlimmer jedoch, dass hier auch Columns mit der Einstellung visible = false einfach mit der Maus angezeigt werden können. Sei es die Ziehen des Dividers oder durch Doppelklicken.

Da TListView ja Nachrichten vom Header empfängt hatte ich bereits angefangen die WNDProc umzuschreiben und einige Header-Ereignisse abzufangen. Zum Teil funktioniert es, aber der Doppelklick auf den Header wird dennoch mit dem Anzeigen von versteckten Spalten quittiert.

Alles in Allem sind beide Komponeten so wie sie jetzt sind für mich nicht brauchbar.

Ich schaue mir einmal die TTreeListView-Komponente von BeniBela an (danke dafür).
Sieht auf jedenfall vielversprechend aus und die Tree-Möglichkeit hätte ich das ein oder andere Mal bereits in einem Grid zur Verwendung bringen können.


Hat vielleicht noch jemand Ideen?

Falls alle Stricke reissen, dann müsste ich eine der beiden Komponenten mit allen Unterkomponenten umschreiben, damit das Verhalten meinen Bedürfnissen entspricht. Dies wollte ich allerdings aus Zeitgründen nicht unbedingt in Angriff nehmen.


vielen Dank aber an Alle, welche bislang im Thread geantwortet haben.
.
Dateianhänge
project1.zip
(3.82 KiB) 66-mal heruntergeladen

atari1040
Beiträge: 21
Registriert: So 27. Dez 2020, 12:10

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von atari1040 »

Ich kann den Titel dieses Threads gut nachvollziehen.
Ich versuche den Einsatz von Fremkomponenten wie TMS usw. nach Möglichkeit zu vermeiden und so habe ich vor kurzem mal wieder TStringGrid verwendet.
Für mich war das irgendwie ein Ausflug in die 90er Jahre zurück. Diese Komponenten sind im Standard nicht mehr zeitgemäß. Leider. Um das Grid einigermassen sinnvoll einsetzen zu können muss man schon viel anpassen.
Ausserdem arbeitete TStringGrid mit einigen Properties und Events auch nicht so wie erwartet, um nicht zu sagen fehlerhaft.
Ich möchte kein Bashing betreiben, denn Lazarus ist wunderbar und es ist Free. Wenn man kritisch ist, dann ist man aber nicht gleich verbohrt.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von wp_xyz »

atari1040 hat geschrieben:
So 22. Mai 2022, 10:36
Ausserdem arbeitete TStringGrid mit einigen Properties und Events auch nicht so wie erwartet, um nicht zu sagen fehlerhaft.
Wie soll ein Lazarus-Entwickler nun erahnen, was da nicht so ist wie erwartet oder was für ein Fehler vorliegt?

Wenn du meinst, dass etwas nicht stimmt, solltest du dir die Zeit nehmen, und einen Bugreport auf gitlab schreiben und ein einfaches Beispielprojekt beifügen, das den Fehler zeigt. Dann kann sich jemand das näher ansehen. Mit einiger Wahrscheinlichkeit wird das behoben, falls es wirklich ein Fehler ist und nicht etwa den User bedingt. Oder mehr noch: Du vertiefst dich (wie der Entwickler auch) in den Quelltext und schreibst einen Patch. Das wäre Open-Source in Reinform.

atari1040
Beiträge: 21
Registriert: So 27. Dez 2020, 12:10

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von atari1040 »

wp_xyz hat geschrieben:
So 22. Mai 2022, 11:14
Wie soll ein Lazarus-Entwickler nun erahnen, was da nicht so ist wie erwartet oder was für ein Fehler vorliegt?
Ja klar, da hast Du Recht, aber das war ja nicht Thema dieses Threads. Es ging um die nicht mehr zeitgemäße Komponente TStringGrid.
Wenn ich Zeit habe könnte ich mal einen Bug Report für die Probleme erstellen aber viel wichtiger wäre mal eine Modernisierung der Komponenten die noch an Zeiten von Windows 95/NT erinnern. Ich bin nun seit 1995 Nutzer von Delphi und später Lazarus aber die Nutzung ist meinerseits leider nur noch Liebhaberei, denn das Geld wird als Entwickler woanders verdient. Ich bin allerdings großer Fan von Lazarus und würde mich freuen wenn sich da mehr bewegen würde.

wp_xyz
Beiträge: 4869
Registriert: Fr 8. Apr 2011, 09:01

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von wp_xyz »

atari1040 hat geschrieben:
So 22. Mai 2022, 14:07
aber viel wichtiger wäre mal eine Modernisierung der Komponenten die noch an Zeiten von Windows 95/NT erinnern.
Wie das denn? Hast du Themenunterstützung aktiviert? "Projekt" > "Projekteinstellungen" > "Manifest-Ressource verwenden (und Themen aktivieren)" markieren. Ist eigentlich per Default aktiviert. Oder bist du nicht auf Windows? Aber unter Linux ist die Themenunterstützung noch viel vielfältiger... Ich verstehe das nicht.

PascalDragon
Beiträge: 825
Registriert: Mi 3. Jun 2020, 07:18
OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
CPU-Target: Aarch64 bis Z80 ;)
Wohnort: München

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von PascalDragon »

atari1040 hat geschrieben:
So 22. Mai 2022, 14:07
Wenn ich Zeit habe könnte ich mal einen Bug Report für die Probleme erstellen aber viel wichtiger wäre mal eine Modernisierung der Komponenten die noch an Zeiten von Windows 95/NT erinnern.
Was ist denn deiner Meinung nach nicht zeitgemäß für die Komponente?
FPC Compiler Entwickler

atari1040
Beiträge: 21
Registriert: So 27. Dez 2020, 12:10

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von atari1040 »

Ich kann das natürlich nur aus meiner Sicht und Erfahrung darstellen und diese mag nicht für alle gelten.
Zuerst mal ganz allgemein: Die komponentenbasierte Entwicklung mit Objektinspektor hat sich grundsätzlich überholt.
Wir haben seit Delphi 1 in großen Konzerne über fast 3 Jahrzehnte sehr viele Delphi Entwicklungen in Betrieb gebracht und das Problem ist die Pflege und Wartung dieser Software.
Mittlerweile gibt es unendlich viele virtuelle Maschinen und Delphi sowie Lazarus Instanzen. Warum? Sowohl im Delphi als auch im Lazarus ist es nicht möglich, Komponenten unterschiedlicher Versionen für Projekte einzusetzen. Die IDE ist grundsätzlich mit einer bestimmten Version der Komponenten verheiratet. Im Hobbybereich ist das alles kein Problem, ich weiss. Die große Menge von VM's und Lazarus Instanzen ist irgendwann nicht mehr überschaubar und wir sind dazu übergegangen moderne Systeme einzusetzen, wo man seine Frameworks, Komponenten und Libraries projektbezogen installiert. Das aber nur am Rande.

Zurück zum TStringGrid: Ich bin unterwegs und wollte mir mal eben auf meinem Mac Lazarus installieren aber das ist wie schon seit Jahren nicht so einfach und daher muss ich jetzt auf Reisen die Frage mal aus dem Gedächtnis beantworten. Viele Anforderungen wurden ja schon weiter oben von anderen genannt. Natürlich müsst ihr bei der Weiterentwicklung immer die Kompatibilität im Auge haben aber was mir fehlt ist ein Zugriff über columByName und nicht nur über den Index, ein Footer mit Summary, einfacher Zugriff auf selectedRows, rowIndex wenn ich auf eine Zeile klicke in einem OnSelect Event sind so die Dinge die mir auf die Schnelle einfallen. Vielleicht ist das in der aktuellen Version ja schon verfügbar, ich weiss es nicht.
Für uns ist ein TStringGrid, also ohne direkte Datenbankanbindung wie das DBGrid, viel wichtiger, da wir viele Daten heute nur noch über REST-API's abfragen und zur Anzeige bringen müssen. Wenn das alte TStringGrid wegen der Kompatibilität so bleiben muss könnte man ja auch über ein TAdvancedStringGrid nachdenken.
Abschliessend nochmal: ich finde FreePascal und Lazarus sehr gut.

Benutzeravatar
fliegermichl
Lazarusforum e. V.
Beiträge: 1430
Registriert: Do 9. Jun 2011, 09:42
OS, Lazarus, FPC: Lazarus Fixes FPC Stable
CPU-Target: 32/64Bit
Wohnort: Echzell

Re: TStringgrid vs TListView - die Wahl zwischen Pest oder Cholera

Beitrag von fliegermichl »

Dann ist der VirtualStringTree doch die beste Wahl. Etwas höhere Lernkurve aber brutal flexibel.

Antworten