Projektoptionen werden nicht gespeichert?

[stifflersmom]

Moin,

irgendwie schaffe ich es nicht verlässlich, meine Projektoptionen zu speichern.
Im Realesebereich tauchen immer wieder die Debuginformationen auf, die ich in der release Version aber gar nicht haben möchte...
Was muss ich löschen/ändern/beschwören, damit das dauerhaft gespeichert wird.

Das ist ein Projekt, dass ich in 10.2 Tokyo bearbeite.

Gruß

Ich muss das Präzisieren:
Ich kann alles Einstellen wie ich will, aber kompiliere ich, sind meine Änderungen in den Optionen hinfällig und die Debuginformationen sind wieder aktiviert.

[KodeZwerg]

Delphi Projekt schließen -> die ".dproj" Datei aus dem Ordner entfernen -> Delphi Projekt öffnen -> alle Grundeinstellungen richtig setzen/prüfen -> fertig.

Bei einem "nacktem" Delphi sollte nun alles wie erwartet funktionieren.
Wie es mit Zusätzen wie GExperts, CNpack etc ausschaut weiß ich nicht.

[stifflersmom]

Jo, gespeichert wirds jetzt.
Danke Dir

[KodeZwerg]

Das freut mich das es nun klappt!

Schade finde ich es das es keinen ".dproj" Validator gibt.
Gerade Project-Options mit indiv. Manifest oder Resourcen gehen auf diese Weise erstmal flöten.

Ich behalte meist eine lauffähige .dproj woanders gesichert, vor allem bei selbst erstellten Zusatz-Krams (Manifest/Resourcen...).

[Aviator]

Vielleicht sollte man noch erwähnen, dass die Einstellungen von vorherigen Konfigurationen vererbt werden. Wenn also in "Allen Konfigurationen" ein Schalter gesetzt ist, dann ist der auch in der Release Konfig aktiv. Du musst den dann also in der "Alle Konfigurationen" entfernen und in der "Debug Konfig" bspw. wieder hinzufügen. Zumindest ist das mein Wissensstand und ich habe auch meine ich des Öfteren von Uwe Raabe bereits das Gleiche gelesen.

[dummzeuch]

Zitat von KodeZwerg:

Schade finde ich es das es keinen ".dproj" Validator gibt.

Zumindest ein Tool, um dproj-Datein aufzuräumen gibt es: Project Magician von Uwe Raabe. Kann ich nur empfehlen.

Zitat von KodeZwerg:

Ich behalte meist eine lauffähige .dproj woanders gesichert, vor allem bei selbst erstellten Zusatz-Krams (Manifest/Resourcen...).

Ich hätte die dproj-Datei auch nicht gelöscht und neu angelegt, sondern die alte nur verschoben und sie dann mit der neun erzeugten verglichen. Das führt manchmal zu interessanten Erkenntnissen.

[KodeZwerg]

Ein Problem mit ähnlichen Symptomen bei mir ist:
Projekt einer alten Delphi Version in eine neue Delphi Version zu verfrachten.
Die IDE nennt keine Fehler wenn sich die internen .dproj Innereien geändert haben.
Man wundert sich nur das keine Einstellungen angewandt werden bzw es beim Compilen zu nichts-sagenden Fehlern kommt.
Oder beim Aufruf der neu erzeugten .exe es zu violations kommt weil Resourcen nicht mehr da sind.
Ob da Uwe sein Programm mit klar kommt? (Versions Unterschiede des .dproj aufbau)

[himitsu]

Die DPROJ ist versioniert, bzw. sie hat sogar zwei Versionsnummern.

Eigentlich ist die DPROJ ein Script und keine Settingsdatei.
Sie wird von oben nach unten durchlaufen und der Letzte, der einen Parameter (Variable) setzt, der wird genommen.

Wenn sich in der DPROJ Optionen verschieben, aber nachfolgend Diese überschrieben werden, durch den "Code" einer älteren/neueren Delphi-Version, dann gibt es Probleme.
z.B. die Interfaces in der OpenToolsAPI setzen teilweise die Optionen im "falschen" Pfad und dann zeigt sogar in der selben Delphi-Version der Optionsdialog was anderes an, als dann beim Kompilieren gemacht wird.


Ich war mal auf die Idee gekommen "falsche" Settings in unseren Projekten via OTA ändern zu wollen ... das war echt ein Spaß.

[TurboMagic]

Sind diese OTAPI Probleme in QP erfasst? Sonst werden die wohl nie beseitigt...

[Uwe Raabe]

Es gibt keine OTAPI-Probleme in diesem Bereich, außer einen Mangel an Dokumentation. Wenn man weiß, wie man es machen muss, funktioniert es auch.