String im Speicher zerstört

[EWeiss]

Wenn ich mein Fenster schließe von dem aus mein String übergeben wird
zerstört das den String im Speicher obwohl dieser in meiner Variable laut Debugger
vorher schon angekommen ist.

Wie kann ich das verhindern?
Kann doch nicht sein das ich mein Fenster so lange geöffnet lassen muss bis der String verarbeitet wurde.

String wird zerstört

Delphi-Quellcode:

if BrowseForFile.OutPutFile <> '' then
begin
  MainApp.Newfile := BrowseForFile.OutPutFile; // kommt hier an alles IO
  BrowseForFile.DestroyWindow();
  BrowseForFile := nil;
  MainApp.SampleAudioStream(MainApp.Newfile); // Hier dann nur noch Kauderwelsch
end;

String funktioniert

Delphi-Quellcode:

if BrowseForFile.OutPutFile <> '' then
begin
  MainApp.Newfile := BrowseForFile.OutPutFile; // kommt hier an alles IO
  ShowWindow(BrowseForFile.Handle, SW_HIDE);
  MainApp.SampleAudioStream(MainApp.Newfile); // alles IO
end;
  BrowseForFile.DestroyWindow();
  BrowseForFile := nil;

gruss

[Zacherl]

Datentyp tatsächlich String, oder eventuell nur PChar?

Bei PChar müsstest du einmal konkret in String casten, damit eine Kopie erzeugt wird.

[EWeiss]

Zitat von Zacherl:

Datentyp tatsächlich String, oder eventuell nur PChar?

Bei PChar müsstest du einmal konkret in String casten, damit eine Kopie erzeugt wird.

PWideChar..
Habe es mit StrPLCopy und StrCopy versucht das gleiche Problem.
Das seltsame ist es tritt sporadisch auf. (zufällig)


EDIT:
Hmm seltsam im Moment gibt es keine Probleme..

gruss

[Zacherl]

Probiers mal einfach nur mit String(PCharValue) . Dass das Problem nur sporadisch auftritt liegt am Memory Manager. Dem steht es frei den Speicher nicht direkt für andere Sachen zu benutzen. Unter Umständen liegt dein String bis zum Ende des Programms völlig unverändert an seiner initialen Speicherstelle. Aber halt nur unter Umständen. Wahrscheinlicher ist, dass der Speicher recht zeitnah mit neuen Daten gefüllt wird und dein String somit überschrieben ist.

[EWeiss]

Zitat von Zacherl:

Probiers mal einfach nur mit String(PCharValue) . Dass das Problem nur sporadisch auftritt liegt am Memory Manager. Dem steht es frei den Speicher nicht direkt für andere Sachen zu benutzen. Unter Umständen liegt dein String bis zum Ende des Programms völlig unverändert an seiner initialen Speicherstelle. Aber halt nur unter Umständen. Wahrscheinlicher ist, dass der Speicher recht zeitnah mit neuen Daten gefüllt wird und dein String somit überschrieben ist.

Werde ich mal versuchen
Danke für die Info.

gruss

[hoika]

Hallo,
UnicodeString als Typ sollte das Problem auch lösen.

[EWeiss]

Zitat von hoika:

Hallo,
UnicodeString als Typ sollte das Problem auch lösen.

Hat eigentlich nichts mit Unicode (Hab ich ja schon PWideChar) zu tun..
Es kommen falsche werte im PWideChar.. ganz am Schluss erst kann ich einen teil des Pfades lesen der ausgewählt wurde.
Ganz normal in Deutscher Schrift.

Oder ich verstehe jetzt nicht genau was du meinst.

gruss

[jaenicke]

Der Unterschied ist, dass ein Delphi-String (String, UnicodeString, AnsiString) referenzgezählt ist, P*Char aber nicht. Irgendwo in deinem Quelltext hast du einen String, den du in dem PWideChar hast. Das ist nur ein Pointer auf diesen String.
Heißt: Sobald der ursprüngliche String zerstört wird, ist der Pointer kaputt.

Was du machen kannst: Solange wie möglich mit String arbeiten und erst bei der Übergabe an eine Schnittstelle auf PChar gehen, damit dann der Aufrufer selbst den String noch hat. Oder selbst Speicher für den PChar reservieren und nicht casten, sondern den String dorthin kopieren.

[EWeiss]

Ich habe es mal auf UnicodeString geändert.
Muss jetzt mal beobachten ob das Problem nochmals auftritt.

Danke.

gruss