Das Problem beim zusammenklicken von Anwendungen mit DBEdits ist doch eher der, das alle Bezüge verloren gehen, wenn das Datenmodul mal nicht geladen ist. Mir geht das gehörig auf den Keks, und zwar so, das ich die Zuweisung wirklich per Hand im FormCreate bzw. FormActivate vornehme. Der Designer hilft mir, meine Formulare zu gestalten und datensensitive Steuerelemente mit Beispieldaten anzupassen, aber ich hüte mich davor, die Life-Einstellungen im Code beim Start als gegeben vorauszusetzen.
So sind z.B. alle Datenverbindungen beim Start per se (GExpert sei dank) geschlossen, alle Tabellen nicht verbunden usw. So kann ich kontrolliert eine Verbindung aufbauen und bei Problemen gezielt Aktionen starten.
Die TDatasource ist im Bearbeitungsformular. Dann öffne ich die Tabellen und Queries kontrolliert. Wenn die Daten geladen sind, verbinde ich die
Query mit dem TDatasource und fertig. Der Bezug vom TDatasource zu den Steuerelementen ist ja gegeben, da geht also nichts verloren.
Ich würde also die Felder wirklich per Hand erzeugen. Das ist eine einmalige Arbeit und dauert in der Umsetzung 1-2 Tage. Hier sind dir die GExperts (Component to Code) vielleicht eine kleine Hilfe.
Das Zusammenklicken von Anwendungen ist toll fürs Prototyping und auch für Anwendungen bis zu einer gewissen Komplexität. Und eben zum Designen von Formularen. Aber sonst sollte man wirklich alles per Hand machen. Gut, die persistenten Felder... die sind auch praktisch...
... und wenn Du nur die Stringfelder manuell erzeugst? Kopiere die Deklaration des persistenten Feldes in den Public-Bereich deines Datenmoduls, entferne den Eintrag aus der
DFM und erzeuge diese Felder dann per Hand (im DatamoduleCreate). Das wäre für den Rest der Anwendung völlig transparent und Du reduzierst gleichzeitig den Aufwand auf ein Minimum. Da reicht schon eine projektweite Suche nach 'TStringField'...