Hallo,

nachdem ich ca 2 Stunden lang in diversen Foren inkl. diesem nach einer Lösung meines Problemes gesucht habe poste ich jetzt einfach meine Frage:

Ich möchte den Text bestimmter Felder im DBgrid zur Laufzeit ändern und durch einen anderen ersetzen (der nicht in der DB gespeichert werden soll).

Beispiel:
In meiner DB gibt es ein Feld mit Integerwerten von 0-5. Bei 0 soll im DBGrid nicht 0 stehen sondern ein Textstring.

0 > bestellt
1 > geliefert
2 > versandt

usw.

Ich habe jetzt hier nachgelesen das das mit OnGetText der TField Komponente funktionieren soll:

Zitat:

Nochmal, sowohl für die Lösung dieser Aufgabe als auch für die calculated Fields ist nicht das DBGrid zuständig, sondern die TDataset-Komponente. Per Doppelclick auf die verwendete TDataset -Komponente kann man persistente Felder erzeugen, die dann wiederum das oben erwähnte Ereignis besitzen.

Aber ich will das ganze ja nicht mit einem Doppelklick machen und dort eintragen sondern eben zur Laufzeit, am Besten im DrawColumnCell Event und sobald in der Spalte der Wert 1, 2, 3 usw auftaucht gegen einen String tauschen.

Habt ihr eine Lösung?

Zitat von kico:

Aber ich will das ganze ja nicht mit einem Doppelklick machen und dort eintragen sondern eben zur Laufzeit, am Besten im DrawColumnCell Event und sobald in der Spalte der Wert 1, 2, 3 usw auftaucht gegen einen String tauschen.

Da hast du evt. etwas missverstanden. Der Doppelklick bezieht sich nicht auf das Ereignis, sondern darauf wie man ein persistentes Feld anlegt mit dem du das Ereignis onGetText nutzen kannst. Das Gegenstück dazu ist dann onSetText.

hallo kico!

Zitat:

Ich möchte den Text bestimmter Felder im DBgrid zur Laufzeit ändern und durch einen anderen ersetzen

für mich schreit dieses aussage förmlich nach der verwendung eines lookup-feldes.
wie willst denn sonst einen string in ein tabellenfeld eintragen, welches als integer definiert ist?

mfg, stefan

Hallo,

wie Grayfox schreibt, sind da wohl Lookupfelder am besten geeignet. Zudem gibt es nette DBGrid Komponenten, wo man dann auch direkt aus einer Dropdonwlist wählen kann. Sehr praktisch also.

Was noch ginge, ist Calculated Fields zu verwenden. Die dienen allerdings nur der Anzeige, nicht jedoch zum Editieren gedacht. So bräuchte man also eine zusätzliche Spalte. Man sollte aber bedenken, daß bei berechneten Felder nie ein Eintrag hinzukommen darf, ohne das Programm neu kompilieren zu müssen.

Also ein Lookupfeld zu verwenden ist sicherlich die beste Wahl.

Gruß,
Tom

Zitat:

wie willst denn sonst einen string in ein tabellenfeld eintragen, welches als integer definiert ist?

Erwähnte ich bereits "onSetText"?

Hallo

Ich würde das Ganze mit dem OnCalcFields Ereignis der Abfrage lösen. Diese Abfrage ist an die DataSource gebunden von der aus Dein DBGrid seine Daten erhält.

procedure TForm.queryCalcFields(DataSet: TDataSet);
begin
query.DisableControls;
case queryIntegerwert.Value of
0 : queryBerechnetesFeld.Value := 'String0';
1 : queryBerechnetesFeld.Value := 'String1';
2 : queryBerechnetesFeld.Value := 'String2';
else queryBerechnetesFeld.Value := 'String Else'
end;
query.EnableControls
end;

Anschliessend hinzufügen der Felder zu query falls noch nicht geschehen (mit Doppelclick auf Abfrage und dann rechte Maustaste):
- 'Integerwert' ist das Feld aus Deiner Abfrage mit den Integer-Werten 0-5
- 'BerechnetesFeld' wie der Name sagt als berechnetes Feld hinzufügen. Im DBGrid muss dann dieses angezeigt werden (hinzufügen!).


So das müsste funktionieren!
Ich hoffe das löst Dein Problem

gruss armin

Zitat von aschne1:

So das müsste funktionieren!
Ich hoffe das löst Dein Problem

Und wie soll dieses berechnete Feld im Grid verändert werden? Ausserdem bist du somit unflexibel, wenn es heißt die Liste der Werte zu ergänzen!

Gruß,
Tom

Hallo Tom

Das berechnete Feld könnte zum Beispiel aus einer weiteren Datenbank stammen die beliebig erweitert werden kann. So müsste das Programm nicht neu compiliert werden und man ist wieder fexibel, oder? Ausserdem könnten die berechneten Werte in Anhängigkeit vom Integerwert aus verschiedenen Abfragen/Tabellen stammen. Ich zum Beispiel, greife im case-Abschnitt auf verschiedene eigene Klassenmethoden zurück!
Sicher der Programmieraufwand ist grösser, aber so flexibel ist die Lookupfeld-Variante nicht!?

Ich wollte dem kico nur ein einfaches Beispiel aufzeigen ohne die Funktion zu überladen und vom Wesentlichen abzulenken.

Für welchen Weg man sich entscheidet ist Geschmacksache.

Gruss
Armin

Hallo Armin,

ich geb dir Recht, daß für die Anzeige des berechneten Feldes ein einziges Lookupfeld nicht immer ausreicht, und es je nach Komplexität mehrere Vergleiche von Werten benötigt, um das berechnete Feld zu füllen... Ich stimm dem zu, was das Berechnen und Anzeigen angeht.

Aber mich stört immer noch an deinem Ansatz, was und wie willst du jetzt in der Datenbank speichern. Berechnete Felder lassen sich nicht speichern. Und das ist auch gut so, denn es soll stets vermieden werden, irgendwas in einer Datenbank zu speichern, was auf irgendeine Weise berechnet werden kann, da es sonst zu Redundanz kommt. Lediglich die Rohdaten gehören da rein, alles andere ist Angelegenheit für Views oder Stored Procedures, ein entsprechenes Datenbanksystem und Datenbankstruktur vorausgesetzt... Also so zumindest hab ich das an der Uni mal gelernt.

Gruß,
Tom

Hallo Tom

Du hast vollkommen Recht, man speichert nur die Rohdaten in einer DB!
Ich speichere die Daten aus einem oder mehreren Feldern einer Abfrage in einer Delphi-Variable! Der berechnete Ausdruck greift auf die Variable zu und zeigt diese im DBGrid an. Die Variable wird nicht in der DB gespeichert!!

Vielleicht schiesst man mit meiner Version für 5 Werte mit Kanonen auf Spatzen?

Sorry!

Servus
Armin