*.dfm bedingt compilieren / TStringfield - TWidestringffield

[Rainer Wolff]

Hallo Delphianer,

so je nach freien Zeitabschnitten versuche ich mich ja ab und an daran, meine bestehenden Apps auf D2010 zu konvertieren.
Bisher läuft bei mir alles auf D2006 und IBX/Firebird.

Da IBX und FB nicht mehr zusammen tun (ich weiss, es war nie unterstützt, aber mit D2006 hats noch funktioniert, warum jetzt nicht mehr?), habe ich ein wenig mit dbExpress rumprobiert. In D2006 kann ich FB-Tabellen auch mit dem Interbase-Treiber öffnen, und für D2010 habe ich mir den freien FB-Treiber von http://groups.google.com/group/dbxfirebird geholt.

Allerdings habe ich in der Kombi das Problem, dass Stringfelder einmal als TStringfield, und einmal als TWidestringfield eingebaut werden. Gibt es eine Möglichkeit, diese unterschiedlichen Typen bedingt zu compilieren (würde ja aber auch die *.dfm betreffen).

Oder kann ich irgendwie alle Felder auf TString- bzw. TWidestringfield zwingen (was mir in Versuchen bis jetzt nicht gelungen ist).

Ich weiss, dass es noch andere Treiber gibt, aber das ist meist Löhnware, und da fehlen mir erst mal die zwingenden Argumente, um mich selbst und Chef zu überzeugen, Geld für etwas auszugeben, was im Moment mit D2006 wunderbar tut und wo ich selbst noch nicht weiss, wieviel mir ein Umstieg auf D2010 bringen würde (zumal es ja noch weitere Probleme mit dem Hochkonvertieren gibt, z.b. Reports).

Gruß Rainer

[hoika]

Hallo,

du benutzt also persistente Felder.
Das würde ich einfach mal zu vermeiden zu versuchen.

Unter D2010 ist halt jetzt jeder normale String ein Unicode-String.


Heiko

[mjustin]

Zitat:

Zitat von hoika

Hallo,

du benutzt also persistente Felder.
Das würde ich einfach mal zu vermeiden zu versuchen.

Sind persistente Felder auch schon ein Anti-Pattern :P ? ... Bisher fand ich dass ihre Vorteile die Nachteile überwogen.

Jetzt aber zweifle ich daran, z.B. da sie auch eine Unicode-Migration einer InterBase Datenbank erschweren. Aus dem gleichen Grund wie oben: TStringField geht nicht mehr, es muss TWideStringField sein. Ein Workaround, der mir das Überarbeiten von ca. sechzig Datenmodulen ersparen würde, wäre herzlich willkommen...

[Rainer Wolff]

Zitat:

Zitat von hoika

Hallo,

du benutzt also persistente Felder.
Das würde ich einfach mal zu vermeiden zu versuchen.

Unter D2010 ist halt jetzt jeder normale String ein Unicode-String.


Heiko

Wenn ich bis jetzt was besseres gefunden hätte...
Ist doch nun mal das einfachste, wenn ich Daten bearbeiten will: Query-Clientdataset-Datasource-DBEdit.

Alle DBEdit von Hand im Quellcode zuweisen?
ORM? (bis jetzt hab ich noch nix gefunden, was mich überzeugt hat)
Sonstiges?

Gruß Rainer

[BUG]

Evtl. ist es ja möglich, zwei verschiedene DFMs pflegen und bedingt einzubinden.

Delphi-Quellcode:

{$IFDEF FOO}
  {$R foo.dfm}
{$ELSE}
  {$R bar.dfm}
{ENDIF}

statt

Delphi-Quellcode:

{$R *.dfm}

Das mal so als Gedanke, nicht getestet und keine Erfahrungen damit.

[Rainer Wolff]

Den Gedanken mit unterschiedlichen *.dfm Files hatte ich auch schon kurz, aber das erscheint mir bei der Quelltextpflege zu umständlich, bei jeder kleinen Änderung muss ständig die zweite dfm mit geändert werden, und was bei der Formularvererbung dann passiert, ist auch eine Frage, die untersucht werden müsste.

Rainer

[sx2008]

Zitat:

Zitat von mjustin

Sind persistente Felder auch schon ein Anti-Pattern :P ? ... Bisher fand ich dass ihre Vorteile die Nachteile überwogen.

Irgendwie schon.
Das Problem mit den persistenten Felder ist dieses "Alles oder nichts"-Verhalten.
Man möchte vielleicht nur den Feldern ein DisplayLabel geben.
Wenn man dann persistente Felder verwendet, dann sind die Feldlängen aller Stringfelder quasi zementiert.
Werden dann die Stringfelder in der unterliegenden Datenbank verlängert spiegelt sich dies nicht in der Anwendung wieder.
Man sollte also wann immer möglich auf persistente Felder verzichten und Anpassungen der Felder im Event AfterOpen vornehmen.
Kleines Beispiel:

Delphi-Quellcode:

procedure TDataModule1.Query1AfterOpen(Dataset:TDataset);
begin
  (dataset.FieldByName('BPreis') as TNumericField).DisplayFormat := '##0.00';
  dataset.FieldByName('BPreis').DisplayLabel := 'Brutto Preis';
end;

So kann man die Feldeigenschaften der unterliegenden Abfrage übernehmen und nur gezielt einige Eigenschaften verändern.
Leider ist das nicht so bequem wie mit persistenten Feldern aber man kommt damit weiter.

[alzaimar]

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... :gruebel:

:zwinker: ... 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'...

[Rainer Wolff]

Zitat:

Zitat von alzaimar

:zwinker: ... 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'...

Das hört sich praktisch an, Danke für den Tipp

[mjustin]

Zitat:

Zitat von alzaimar

:zwinker: ... 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'...

Geht das? Ich denke, sobald man Felder manuell erzeugt, sind nur noch diese sichtbar und keines mehr. Darüber stolpert man zum Beispiel, wenn man ein kalkuliertes Feld benötigt. Allein dieses 'zu Fuss' erzeugen, geht nicht, alle anderen Felder des Datasets sind dann unsichtbar - man muss alle erzeugen, die benötigt werden. (Also entweder alle persistent, oder alle selbst erzeugen). Oder ist das in neueren Delphi Versionen geändert worden?

Viele Grüße,