Benutzt denn niemand das inzwischen im Delphi mitgelieferte DUnitX und dessen GUI?

Zitat:

[dcc64 Fehler] E1026 Datei nicht gefunden: 'DUnitX.Loggers.GUI.VCL.dfm'

Bzw. kompiliert niemand seine eigenen Komponenten/SharedCodes vor und stellt seinen Projekten nur noch die DCUs bereit?

• Nur den/die DCU-Ausgabepfad(e) und eventuell noch den/die DCP-Ausgabepfad(e) im Compiler-Suchpfad (SearchPath/LibraryPath)
• und optional die Sourcen (PAS) bloß im Editor-Suchpfad (BrowsingPath)

https://quality.embarcadero.com/browse/RSP-42284

Einfache Antwort: Nein.

Alles, was es auch aus anderen Quellen im Sourcecode gibt, verwende ich von dort. Die von Embarcadero mitgelieferten Bibliotheken sind in der Regel veraltet und, wie Du bemerkt hast, unvollständig.

Interessanterweise gibt es separate Compiler Parameter für die Units (-U) und die Ressourcen (-R). Damit ließen sich die DFMs im Source problemlos an den Compiler übergeben ohne dass er die Unit-Sourcen sieht. Für die übersetzten Ressourcen gibt es in den Einstellungen auch einen separaten Eintrag, aber leider nicht für die nicht-übersetzungsrelevanten und auch nicht in den Projekt-Optionen. Neben den entsprechenden Einstellungen in der IDE müssten dann aber noch Anpassungen in den .targets erfolgen.

Im Code sind sie ja drin, aber wäre toll, wenn man ohne die Commanozeile sowas direkt nutzen könnte.

Vollständig ist es ja, nur halt nicht alles im "Standard"-Suchpfad zu finden.

Ich habe jetzt schon länger nicht mehr die Entwicklung verfolgt.
Die mitgelieferte GUI war eher nicht so gut. Dieser in die IDE eingebettete GUI fand ich ganz schlimm.

Ich habe für meine Entwickungen eine neue, eigene GUI gebaut. Die funktioniert bis auf kleine Bugs eigentlich ganz gut.

Zitat von Jens01:

Dieser in die IDE eingebettete GUI fand ich ganz schlimm.

Wenn du damit TestInsight meinst, das finde ich eigentlich eine geniale Lösung. Die DUnitX-GUI verwende ich gar nicht. In der IDE nutze ich TestInsight und im FinalBuilder die entsprechende Action.