Beispielprogramm startet nicht

[Delbor]

Hi zusammen
Ich habe hier ein Embarcadero-Beispielprogramm(SQLite_OnAuthorize). Wenn ich das Ding starten will, kriege ich folgende Fehlermeldung:

Zitat:

---------------------------
Sicherungsordner 'C:\Program Files (x86)\Embarcadero\Studio\19.0\source\vcl\__history \' kann nicht angelegt werden.
---------------------------

Das da nichts gespeichert werden kann, ist nur logisch. Aber überhaupt: was ist der 'Sicherungsordner'? Ein Ausgabeverzeichnis? Und was hat das unter 'C:\Programme' zu suchen?

Ich bin weder unter <Projekt=>Optionen> noch unter <Tolls=>Optionen> auf etwas ggestossen, das danach aussieht. Oder nbach was muss ich suchen?

Gruss
Delbor

[mkinzler]

Es fehlen die Schreibrechte für das Verzeichnis.

[Uwe Raabe]

Der Fehler kommt in der Regel dann, wenn du in der IDE (unabsichtlich) etwas an den RTL/VCL/FMX Sourcen geändert hast.

Die Meldung kommt dann nicht vom Programm sondern von der IDE, die vor dem Compilieren/Starten die Änderungen speichern will.

[Delbor]

Hi Uwe Raabe

Zitat:

Die Meldung kommt dann nicht vom Programm sondern von der IDE, die vor dem Compilieren/Starten die Änderungen speichern will.

Ich meine mich zu erinnern, dass ich so einen ähnlichen Fall schon mal hatte - da war irgendwelche Delphi-Unit aus den Sourcen geöffnet, und ich realiesierte erst bei der Fehlermeldung, dass ich versucht hatte, Änderungen an einer Delphi-Unit zu speichern. Die entsprechende Unit liess sich später immer wieder problemlos ööffnen . Auch waren solche Units während des Compilierens immer wieder mal offen.

In diesem Fall liegen die Dinger etwas anders: Die Demoprogramme sind schon seit der ersten Installation nicht mehr da, wo Delphi sie installiert hatte (C:\Programme(x86), sondern liegen in einem Verzeichnis Tokio-Demos auf meinem Entwicklerlaufwerk. Kommt dazu, dass ich mit dieser bewussten Demo noch nicht gearbeitet habe.

Gruss
Delbor

[Delphi.Narium]

Mag ja sein, aber C:\Program Files (x86)\Embarcadero\Studio\19.0\source\vcl\__history\ weist darauf hin, dass eine Datei der VCL geändert wurde (warum auch immer) und nun die Änderungen gespeichert werden sollen.

Die Fehlermeldung resultiert aus einer Änderung in der VCL und nicht aus einer Änderung an den Quellen des Demoprogrammes. Und dabei ist es dann egal, wo die Demoprogramme liegen.

Das Problem ist eine (vermutlich versehentliche und/oder unbemerkt vorgenommene) Änderung an einer Unit der VCL.

[Delbor]

Hi zusammen

Zitat von Delphi.Narium:

Die Fehlermeldung resultiert aus einer Änderung in der VCL und nicht aus einer Änderung an den Quellen des Demoprogrammes. Und dabei ist es dann egal, wo die Demoprogramme liegen.

Das Problem ist eine (vermutlich versehentliche und/oder unbemerkt vorgenommene) Änderung an einer Unit der VCL.

Da sehe ich die Lösung nur darin, die Sourcen auswechseln.

Gruss
Delbor

[jaenicke]

Zitat von Delbor:

Da sehe ich die Lösung nur darin, die Sourcen auswechseln.

Das genannte Demoprojekt bindet keinerlei RTL-/VCL-Units direkt ein. Die einzige Möglichkeit, dass das passiert ist also, dass du zusätzlich zu den Dateien des Projekts (das ist ja nur eine Unit und das zugehörige Projekt) noch weitere Dateien offen hast wie es u.a. Uwe ja bereits geschrieben hat. Du brauchst also nur darauf zu achten, dass du nach dem Öffnen des Projekts keine anderen Units geöffnet hast bzw. diese nicht versehentlich änderst.

Zitat von Delbor:

In diesem Fall liegen die Dinger etwas anders: Die Demoprogramme sind schon seit der ersten Installation nicht mehr da, wo Delphi sie installiert hatte (C:\Programme(x86), sondern liegen in einem Verzeichnis Tokio-Demos auf meinem Entwicklerlaufwerk.

Delphi installiert die schon lange nicht mehr unter c:\Programme (x86). Die landen, wenn ich mich richtig erinnere schon seit etwa 10 Jahren, in den öffentlichen Dokumenten des Rechners.

[Delbor]

Hi zusammen

Soviel ich bis jetzt mitbekommen habe, ist der Grund: Die Beispielprogramme stammen aus verschiedenen Delphi-Versionen. Aktuell geöffnet ist DelphiXE8 mit dem Beispielprogramm
'E:\Delphi Tokio Corner\Delphi Tokio Demos\Samples\Object Pascal\Database\FireDAC\Samples\Getting Started\SQLite'. Das war eines der Programme, die ich gestern in Delphi Tokio versucht hatte, zu starten - mit der bekannten Fehlermeldung.
Dieses Programm verursacht unter DelphiXE8 eine andere Fehlermeldung:

Zitat:

[dcc32 Fataler Fehler] GettingStarted.dpr(12): F1027 Unit nicht gefunden: 'System' oder binäres Äquivalent (.dcu)

Einige der Dateien, die da liegen, tragen noch das Datum vom 15.12.2017 - ein Zeitpunkt, zu dem ich noch kein Tokio hatte.

Ich denke, ich sollte wohl die DCUs und die EXE löschen und/oder das Beispieprojekt unter einem neuen Namen abspeichern.

Gruss
Delbor

[Delbor]

Hi jaenicke
[QUOTE=jaenicke;1408275]

Zitat von Delbor:

Das genannte Demoprojekt bindet keinerlei RTL-/VCL-Units direkt ein. Die einzige Möglichkeit, dass das passiert ist also, dass du zusätzlich zu den Dateien des Projekts (das ist ja nur eine Unit und das zugehörige Projekt) noch weitere Dateien offen hast wie es u.a. Uwe ja bereits geschrieben hat. Du brauchst also nur darauf zu achten, dass du nach dem Öffnen des Projekts keine anderen Units geöffnet hast bzw. diese nicht versehentlich änderst.

Zitat von Delbor:

In diesem Fall liegen die Dinger etwas anders: Die Demoprogramme sind schon seit der ersten Installation nicht mehr da, wo Delphi sie installiert hatte (C:\Programme(x86), sondern liegen in einem Verzeichnis Tokio-Demos auf meinem Entwicklerlaufwerk.

Delphi installiert die schon lange nicht mehr unter c:\Programme (x86). Die landen, wenn ich mich richtig erinnere schon seit etwa 10 Jahren, in den öffentlichen Dokumenten des Rechners.

Ja, stimmt. Unter XE8 hattte ich den Fehler gemacht und die Beispiele verschoben; unter Tokio hatte ich sie kopiert, wesshalb sie immer noch da sind.

Zu ersterem:

Zitat von Uwe Raabe:

Der Fehler kommt in der Regel dann, wenn du in der IDE (unabsichtlich) etwas an den RTL/VCL/FMX Sourcen geändert hast.
Die Meldung kommt dann nicht vom Programm sondern von der IDE, die vor dem Compilieren/Starten die Änderungen speichern will.

Ich hatte mir das Beispiel unter XE8 schon angesehen und es auch compiliert. Und so war/ist in den compilerten Dateien (exe) die XE8-Version einkompiliert. Zumindest verstehe ich das nun so, dass Delphi, sobald ich unter Tokio compilieren will, merkt, das sich die fragliche Datei geändert hat (Tokio-Version versus XE8-Version) und deshalb speichern will.

Zitat von Delbor:

Auch waren solche Units während des Compilierens immer wieder mal offen.

Solange Dateien aus den Sourcen nur in der IDE geöffnet sind, aber nicht explizit dem Projekt hinzugefügt wurden, werden sie nicht mitkompiliert. Dass sie in der IDE geöffnet werden, geschieht 'automatisch' dann, wenn im Projekt selbst ein Haltepunkt gesetzt wird und anschliessend mit F7 weitergesteppt wird.

Gruss
Delbor