Bei einer Datenhaltung in visuellen Komponenten stäubt sich bei mir alles...
Na ja, wenn du die Darstellung eines Datenstrings in einem TCustomEdit schon als
Datenhaltung in visuellen Komponenten verstehst, dann wird das mit der visuellen Darstellung von Daten aber schwierig.
Die datensensitiven Komponenten machen auch nichts anderes als die Daten bei Bedarf aus dem entsprechenden TField zu holen und diese wieder dort abzulegen, wenn sie in der visuellen Komponente verändert wurden (und noch ein bisschen was drumherum mit Formatierung und Prüfung und so, was einem die Arbeit schon gelegentlich deutlich erleichtert).
Ich benutze datensensitive Komponenten schon seit Delphi 1 und werde das auch weiter tun, wenn das eine brauchbare Lösung für das gerade aktuelle Problem sein sollte. Natürlich verwende ich auch andere Ansätze (z.B. meinen
Dataset Enumerator, auch in Kombination mit datensensitiven Komponenten), immer den jeweiligen Anforderungen entsprechend. Datensensitive Komponenten von vornherein auszuschließen finde ich schon etwas - sagen wir
einengend.
Übrigens benutze ich auch schon immer statische Datenbankfeldkomponenten, weil es eben viele Möglichkeiten (zumindest einfacher) bietet, in den datensensitiven Prozess einzugreifen. Die immer wieder auftauchende Abneigung dagegen kann ich nur einer unvollständigen Kenntnis der Zusammenhänge zuschreiben. Oder es ist einfach nur Geschmackssache.
Probleme machen natürlich immer die neuen Komponenten, für die es (noch) kein datensensitives Pendant gibt. Auch dafür gibt es Lösungen, die man nach einmaligem Erstellen immer wieder einsetzen kann. Ein umfassendes Beispiel habe ich vor ein paar Jahren hier beschrieben:
CodeRage Deutschland 2019 - Session 06 - Zwischen DB-Controls und LiveBindings
Bisher hat sich noch keine Notwendigkeit ergeben, aber ich bin fast sicher, dass sich dieses Konzept mit etwas Geschick auch auf FMX anwenden lässt.