Zeilen eines TDBGrid "Blockweise" färben

[Uwe Raabe]

Zitat von RSF:

OK, hast du mein Beispiel aus #4 probiert

Im Unterschied zu Ralph's Anforderung lässt sich dein Status direkt aus dem aktuellen Datensatz ermitteln. Bei der Frage geht es aber darum, alle Datensätze mit gleicher ID auch gleich zu färben und zusätzlich bei jedem Wechsel der ID diese Farbe umzuschalten. Das lässt sich allein aus dem aktuellen Datensatz nicht ermitteln.

@Ralph: Welche Datenzugriffskomponente setzt du denn ein?

[joachimd]

Pack doch ein berechnetes Feld rein, welches den Status "leer bzw 0" (also Farbe ermitteln), "1" (Farbe 1) und "2" (Farbe 2) hat. Dann setze die Farbe anhand dieses Flags.

[Delphi.Narium]

Für die Berechnung sind aber Informationen aus dem vorherigen Datensatz (VorgangsID) erforderlich.
Berechnet Felder beziehen sich aber (soweit ich weiß) auf den aktuellen Datensatz. Der Datensatz enthält also bereits alle zur Berechnung erforderlichen Informationen. Diese Bedingung ist hier aber nicht erfüllt.

[Jumpy]

Zitat von Uwe Raabe:

@Ralph: Welche Datenzugriffskomponente setzt du denn ein?

Da ist eine TADOQuery dahinter, dann TDatasource, dann das TDBGrid.


@all: Danke für die bisherigen Vorschläge. Das Problem hat Uwe gut beschrieben, nicht der aktuelle Datensatz alleine bestimmt ob/wie gefärbt wird.

Ich überlege jetzt (nach dem ersten Zeichnen) eine Event-Prozedur an das OnDataChange der TDatasource zu hängen. Feuert dieses, dann
- weise dem OnDataChange nil zu
- Komplettes Grid.Repaint
- dann weise dem OnDataChange wieder die Prozedur zu
(da das OnDataChange während eines Repaint ohne Ende feuert, muss man das mMn vorher ausschalten).

Komme aber erst später dazu das mal zu testen, da ich gerade nicht in der Firma bin.

[RSF]

@Uwe Raabe Danke für die verständliche Erklärung.
Könnte es eventuell mit einer temporären Tabelle(im dbGrid) mit den erforderlichen Flags gehen. Die entsprechend mit den veränderten IDs aktualisiert wird.
Ich meine damit das Problem auf DB-Ebene zu lösen.
Oder ist der Gedankengang wieder daneben.

[Uwe Raabe]

Zitat von Jumpy:

Da ist eine TADOQuery dahinter, dann TDatasource, dann das TDBGrid.

Ist die Query Read-Only und passt komplett in den Speicher?

In dem Fall könntest du die Daten in ein TClientDataSet oder ein anderes InMemory-Dataset übernehmen und dabei ein zusätzliches Feld für die Farbe besetzen. Da die Übernahme sequentiell erfolgt, kann der ursprüngliche Algorithmus für das Färben verwendet werden.

Das funktioniert natürlich nicht so gut, wenn die Daten im Grid verändert werden. In dem Fall kannst du aber vielleicht ein temporäre Tabelle anlegen und diese als Lookup verwenden. Die Tabelle hat nur zwei Felder (ID, Farbe), wobei ID mit der ID der Originaltabelle identisch ist.

Wenn die Query eine überschaubare Datenmenge zurückliefert, kannst du nach dem Öffnen auch einfach ein Dictionary (ID, Farbe) anlegen. Es läuft darauf hinaus, daß du irgendwie für jeden Datensatz eine Farbe hinterlegst.

[Jumpy]

Hallo Uwe,

jetzt hab ich Stoff zum nachdenken. Die Daten an sich können im Grid nicht verändert werden, aber sie können gefiltert oder sortiert werden, wodurch sich die Reihenfolge ändert. Ich muss mal schauen, ob man nach jeder Fileraktion oder so in zusätzlichen Feldern eines ClientDatasets (wenn ich denn darauf umstelle) die Farbwerte neu vergeben kann.

[jobo]

Zitat von Jumpy:

..
jetzt hab ich Stoff zum nachdenken.

Ich habs nur überflogen, also ggF. nicht ernst nehmen.
Gemäß Uwe sind zwar bei der Färbung einer Gruppe mehrere Datensätze relevant für die Frage ob gleiche Gruppe oder nächste. Das kann ich aber immer mit einem Merker auf den vorigen Datensatz abfangen oder? Ich muss nicht wissen, was alles kommt. Ich muss nur merken, Wert ändert sich also wechsel ich die Farbe.

Dies gilt natürlich nur, wenn die Darstellung gemäß initialer Abfrage/Sortierfolge erfolgt.

Dann filtern/sortieren:
Hier wäre es erstmal eine Frage, was ich erreichen will.
a) Gruppen/Färbung beibehalten (wie original): Visueller Effekt wäre dann, "Flatterfärbung" oder scheinbare Gruppen, obwohl durch Filterung einfach nur andere fehlen und bei Hinundher Farbwechsel dann scheinbar neue Gruppen entstehen.
Der User würde das ggF. als Indikator für "unvollständige " Gruppen sehen/bemerken. Vielleicht deutlicher/besser, wenn mit hinreichend vielen Farben (mehr als 2 ) gearbeitet wird.
b) ich will den "Stile" beibehalten und wende die Färbungsmechanik neu an, bei geänderter Sortierung vorzugsweise auf das neue Sortierfeld.

[hoika]

Hallo,

Zitat:

Ich muss nur merken, Wert ändert sich also wechsel ich die Farbe.

Das sehe ich aber im OnDrawCell von Zeile2 nicht, dass die vorige Zeile eine andere Id hatte.

[Jumpy]

Zitat von hoika:

Hallo,

Zitat:

Ich muss nur merken, Wert ändert sich also wechsel ich die Farbe.

Das sehe ich aber im OnDrawCell von Zeile2 nicht, dass die vorige Zeile eine andere Id hatte.

Genau das ist halt mein Problem. Deswegen merke ich mir die ID der vorherigen Zeile um zu sehen, ob ein Wechsel stattfiden muss. Das funktioniert dann aber nur beim erstmaligen Zeichnen des Grids, wo das von oben nach unten neu gezeichnet wird und dementsprechend die darunterliegende Query einmal von oben nach unten durchlaufen wird.
Wenn ich den Cursor/Selector zwischen den Zeilen hin und her springe, werden nur einzelne Zeilen neu gezeichnet und ich habe nicht den Bezug zu den Zeilen davor. Genau das ist mein Problem.

@Jobo: Sortierung war quatsch, das Grid kann nicht sortiert werden, denn es muss ja immer ala "Order By GruppenID, EinzelID" sortiert sein, damit es überhaupt erst möglich ist zusammenhängende Blöcke zu haben.

Das einzige was passieren kann ist Filterung, d.h. die Datenmenge ändert sich und das Grid müsste eigentlich komplett neu gezeichnet und gefärbt werden. Das eine weiße Zeile dann grau wird oder umgekehrt ist egal. Es geht ja nur darum den einen Block vom nächsten zu unterscheiden. Und deswegen kann dann der Übernächste Block auch wieder die selbe Farbe haben wie der erste.

Ich basteln nachher in der Firma nochmal ein bisschen rum, irendwie muss das doch gehen .