"Duplicate Resource" - das alte Lied

[Codehunter]

Ich habe ein selbstgebautes Package welches selbst auch sauber compiliert. Jetzt mußte ich einige Units einfügen, die zu einer Komponente gehören die in einem anderen Package enthalten sind. Also hab ich das andere Package in die Requires aufgenommen. Wenn ich jetzt mein Package kompilieren will, bekomme ich den Duplicate Resource Error. Ich habe jetzt aber schon sämtliche beteiligten Dateien nach dem berüchtigten "{$R *.irgendwas" durchsucht (per Dateisuche) und alle Vorkommen auf eindeutige Namen ohne Platzhalter geändert. Das Problem besteht leider weiter. Gibt es noch andere Compiler-Anweisungen die den Duplicate Resource Error verursachen können (D5 Pro)?

[Bernhard Geyer]

Sind die units auch im Package der anderen Komponente? Es wird oft vergessen alle Units aufzunehmen was dann in Fällen wie deinen Problem bereitet.

[Codehunter]

In welches Package soll ich jetzt welche Units aufnehmen? Ich hatte jetzt mal probeweise alle Units in mein Package genommen und das andere Package komplett aus der IDE genommen (andernfalls werd ich ja bemeckert daß eine Unit in zwei Packages enthalten wäre). Das Ergebnis war das selbe: Duplicate Resource.

[uligerhardt]

Zitat von Codehunter:

Ich habe jetzt aber schon sämtliche beteiligten Dateien nach dem berüchtigten "{$R *.irgendwas" durchsucht (per Dateisuche) und alle Vorkommen auf eindeutige Namen ohne Platzhalter geändert.

Hast du sowohl *.pas als auch *.dpk durchsucht? Und vielleicht steht irgendwo nicht $R, sondern $RESOURCE?

[Codehunter]

Zitat von uligerhardt:

Hast du sowohl *.pas als auch *.dpk durchsucht? Und vielleicht steht irgendwo nicht $R, sondern $RESOURCE?

1. Ja, per String-in-*.*-Datei-Suche
2. Nein, existiert in keiner beteiligten Datei

Jetzt könnte es nur noch sein, daß eine der externen Units wieder weitere externe (oder VCL-) Units einbindet. Aber das ist dann ein ewig langer Baum von möglichen Dateien, das finde ich nie...

Warum gibts auch keinen Compilerschalter mit dem man dem Ding sagen kann, daß er jede Resource nur einmal einbinden soll. Alles andere macht ja auch überhaupt keinen Sinn.

[Bernhard Geyer]

Zitat von Codehunter:

Warum gibts auch keinen Compilerschalter mit dem man dem Ding sagen kann, daß er jede Resource nur einmal einbinden soll. Alles andere macht ja auch überhaupt keinen Sinn.

Es macht aber auch keinen Sinn ohne Fehlermeldung eine der Ressourcen zu unterschlagen. Es ist ja so das gleiche Ressourcen-IDS verwendet werden aber nicht unbedingt die gleichen Ressourcen/Quelldateien gezogen werden.

[Codehunter]

Ja ok aber diese Duplicate Resource Meldung kommt ja wohl originär nur daher daß man im Schalter {$R ...} auch Wildcards benutzen kann und wenn man jetzt verschiedene Packages (tritt ja meistens in dem Zusammenhang auf) in einander verschachtelt, dann schnappt sich der Compiler bzw. Linker ja tatsächlich ein und die selbe Datei mehrmals. DAS ist doch denke ich ein Bug im Delphi. Ist ja in späteren Versionen vllt. auch behoben worden, weiß ich nicht denn ich muss mich noch mit D5 befassen.

Was ich meinte ist, daß wenn man schon mit Wildcards in Compilerschaltern arbeitet, dann müßte man andererseits sicherstellen daß es dadurch nicht zu Überschneidungen kommen kann. Andernfalls müßte man eben eindeutige Resourcen-Dateinamen vorschreiben und Wildcards verbieten.

Es ist ja leider sogar so, daß Delphi die Wildcards selbst generiert wenn es z.B. findet man in jeder Formular-Unit ein {$R *.dfm} anstatt einem eindeutigen Dateinamen. Wobei .dfm jetzt nicht soooo schlimm sind wie .dcr oder .res in dem Zusammenhang.

Davon mal abgesehen, ich bin mit meinem Problem immernoch kein Stück weiter :-/

EDIT: Problem gefunden *wäääääääääh*.... Ich hatte in einer selbst geschriebenen Komponenten-Unit ein {$R unitname.dcr} explizit OHNE Wildcards stehen. Als ich das externe Package in mein Package verlinkt hatte, muß Delphi eigenmächtig die selbe unitname.dcr noch einmal in die package.dpk aufgenommen, aber auch ohne Wildcard. Das ist so bekloppt, daß ich da gar nicht danach geschaut hatte *gruml*