Änderungen in Units werden nicht erkannt

[cckLoud]

Nur den Inhalt! Die rc bleibt gleich, ist aber ja auch nicht relevant für das Programm. Die dient nur brcc32 zum erstellen der res.

[Uwe Raabe]

OK, dann solltest du den Weg über Ressourcen und Bilder vielleicht doch in Betracht ziehen. Dabei gibst du ja neben dem Ressourcenamen und dem Ressourcentyp insbesondere den Dateinamen an. Diese Datei wird dann dem Projekt hinzugefügt und taucht auch im Projektmanager auf. Das bringt jetzt zwei Vorteile:

1. Es wird deutlich, dass eben diese Datei zum Projekt gehört und nicht nur eine .res oder .rc Datei.
2. Da weder eine res- noch eine rc-Datei existiert, wird die Datei bei jedem Compiliervorgang in eine res-Datei (genauer die *.dres) eingebunden und mit eingelinkt.

Ohne diesen Schritt musst du die res-Datei manuell außerhalb der IDE erzeugen, wenn sich dein Dateiinhalt ändert.

Alternativ kannst du auch die .rc Datei deinem Projekt hinzufügen. Das erzeigt dann einen solchen Eintrag in der dpr: {$R 'test.res' 'test.rc'} Der sorgt dann auch dafür, dass die res-Datei immer neu erzeugt wird. Das funktioniert wie gesagt aber nur, wenn dieser Eintrag in der dpr steht und die .rc in das Projekt aufgenommen wird. In einer Unit wird diese Zeile nur wie ein simples {$R test.res} behandelt.

Mir persönlich gefällt der erste Ansatz aber deutlich besser, weil damit die eigentliche Datei im Projekt aufgenommen wird. Die rec und res sind dann nur Zwischenprodukte, die ja mit den eigentlichen Sourcen und Daten nichts zu tun haben.

Außerdem kann man viele solcher Dateien (txt, html, xml) direkt in der IDE anzeigen und bearbeiten (teilweise auch mit passender Syntaxhervorhebung).

[cckLoud]

Also ich sehe die Vorteile nicht. Das programmierte System erfolgt völlig geschlossen. In einem eigenen Programmm wird das Grid, das später verwendet wird, definiert: ich sage da zB, wieviele Spalten/Zeilen es haben soll, wie breit die Spalten sein sollen, welche Überschrift und welchen Datentyp, welche Formatierung und Ausrichtung sie haben (dabei auch ein Datentyp "InterpretedString", der einen eingegebenen String wie "(2+3)*(4+(3-2)) auswertet und das Ergebnis ermittelt; die Source für den Parser hatte ich damals im Delphi-Treff eingetellt)) und ob Zellen der Spalte editierbar sind oder nicht. Weiterhin kann ich Namen für spalten vergeben, über die später auch zugegriffen werden kann (das erhöht die Übersichtlichkeit des Programmcodes ungemein!). Und, wenn sie aus einer DB stammen, kann die Quelle (Table, Field) angegeben werden. Das alles passt genau ins Konzept meiner anderen Controls wie tXedit, tXMemo, tXcombobox usw.

Aus den Angaben wird vom Programm eine XML erzeugt, die dann automatisch in einer Resource ungewandelt wird. Die res-Datei kann direkt in die Source der zugehörigen Unit "eingebunden" werden(natürlich nur das "{$R myresource.res}").

Der zugehörige Wrapper, in der Unit eingebunden, liest die XML aus der Resource und behandelt das Grid entsprechend. Es wacht zB, darüber, dass in eine Integer-Spalte nur Zeichen eingeben werden können, die zu einer Integer gehören, dass in einer Float-Spalte auch eine gülige Float steht. Er liefert mir einen "oncellchanged-Event, einen Zugriff alla "Cell.asFloat" uvm. Er liefert Zeilen. und Spalten/Zeilensummen, Funktionen zun leeren/löschen von Zeilen/spalte, zum Austauschen uvm. Und als Highlight (finde ich jedenfalls) kann der Inhalt des Grids aus einer DB geladen bzw, gespeichert werden - alles ohne weiteren Code.

Wie sollte da der Eintrag in das Projekt einen Vorteil bringen? Denk daran, was mein Ursprngliches Problem war: Delphi erkannte die Änderung IN DER UNIT (in der die "{$R myresource.res}" per Programm eingetragen wurde! Und wenn es die nicht erkannte, warum sollte es dann die Änderung an der Res erkennen?

Und die Aussicht "taucht auch im Projektmanager auf" gruselt es mich noch mehr. Das Projekt, für das ich das mache (wg/Umstellung von D7 auf D10/D11) hat gereits 500 - 600 Einträge im Projektmanager - und da sollen nun nochmal 200 - 300 dazu kommen? Ehrlich: nein danke!