PChar to String & zurück - Zeichen geht verloren

[ThE_-_BliZZarD]

Hallihallo liebe Delphigemeinde

ein kleines (aber nerviges) Problem mit PChar und Strings..

Ich habe eine Funktion in eine .dll ausgelagert, das einbinden und aufrufen und so weiter funkzioniert auch. Allerdings, da die Funktionen ja ohne die Borlandbiliotheken keine Strings als Parameter übergeben können, habe ich PChar's verwendet. Nun Übergebe ich der Funktion einen PChar in dem "2+3" steht. Das kommt auch an. In der Funktio habe ich dann eine Variable vom Typ Sring erstellt und mittels

Delphi-Quellcode:

String_var := Pchar_var;

Den PChar wieder in einen String verwandelt.
Nun habe ich testweise einfach den String wieder in einen PChar konvertiert via

Delphi-Quellcode:

result := PChar(String_var);
// Result ist natürlich vom Typ PChar..

und zurückgeben lassen.. Allerdings kommt jetzt im Mutterprogramm nur noch der String "2+" zurück, d.h. das letzte Zeichen ist verlorengegangen..

Gesamt besteht meine Funkion aus:

Delphi-Quellcode:

function aufreg(meinParameter: PChar): PChar;
var 
   meinString: String;
begin
   meinString := meinParameter;
   result := PChar(meinString);
end;

//Aufgerufen mit -> PChar('2+3')
//Raus kommt     -> 2+

Wahrscheinlich ist das ein wirklich dämlicher Fehler.. aber er macht mich verrückt.. plz help!

MfG

BliZZarD

[Zacherl]

Füg dem String mal ein #0 hinzu und übergib den Pointer darauf, also @Str[1].

[Dax]

Das #0 am Ende des Strings ist immer da, soweit ich mich erinnern kann.

[ThE_-_BliZZarD]

@Zacherl: Das hab ich jetzt nicht ganz kapiert.. Sry :-(

Würdest du mir ein kleines Codebeispiel spendieren?

[mkinzler]

Wo wird den abgeschnitten? Kommt das richtige in der Dll an?

[ThE_-_BliZZarD]

@mkinzler: ja in der dll kommts richtig an, wenn ich das hier mache:

Delphi-Quellcode:

function aufreg(meinParameter: PChar): PChar;
var
   meinString: String;
begin

   result := meinParameter;
end;

Dann kommt ds richtige raus.. also muss es an den zwei Type-casts liegen..

[brechi]

Du gibts nen Pointer auf eine Lokale Variable zurück. Da ist es total zufällig was zurückgeliefert wird.

[mkinzler]

Dann versuch mal:

Delphi-Quellcode:

result := PChar(meinString+#0);

[DeddyH]

Und so?

Delphi-Quellcode:

function aufreg(meinParameter: PChar): PChar;
var
   meinString: String;
begin
   meinString := StrPas(meinParameter);
   result := PChar(meinString);
end;

[brechi]

Nein versuchs so nicht. Funktionen geben keine PChars zurück. Nimm nen String oder packs als Parameter rein und lass die Aufrufende Funktion den Speicher allokieren.

[mkinzler]

Zitat:

Zitat von brechi

Nein versuchs so nicht. Funktionen geben keine PChars zurück. Nimm nen String oder packs als Parameter rein und lass die Aufrufende Funktion den Speicher allokieren.

Funktionen in Dlls schon!

[ThE_-_BliZZarD]

@mkinzler: Danke.
/me sets mode: +gott mkinzler

Das wars.. *freu* tausend dank xD

Lösung falls jemand auch mal dieses Problem hat:

Delphi-Quellcode:

function aufreg(meinParameter: PChar): PChar;
var
  meinString: String;
begin
   meinString := meinParameter
   result := PChar(meinString+#0);
end;

[mkinzler]

Wurde doch schon von Dax vorgeschlagen, habe nur seinen Vorschlag in deinen Code eingebaut.

[Dax]

Zitat:

Zitat von brechi

Nein versuchs so nicht. Funktionen geben keine PChars zurück. Nimm nen String oder packs als Parameter rein und lass die Aufrufende Funktion den Speicher allokieren.

/signed

Wenn man es anders löst, wird man sich vor nicht auffindbaren Speicherlecks nach einer Weile nicht mehr retten können.

[brechi]

wtf? Entweder ich hab nen Denkfehler weil ich noch zu besoffen bin, hab das Prinzip von String/PChar in Delphi nicht verstanden oder ihr programmiert alle grauenhaft.

Strings werden von Delphi verwaltet, sind also auch gültig wenn man sie als Rückgabewert missbraucht.

PChar ist das selbe wie ein Pointer. Und wenn ihr das so programmiert dann ist dieser Pointer nicht mehr gültig da dieser auf eine Lokale Variable zeigt. Sowas macht man eben nicht.
Machs so wie MS mit ihren APIs: Sobald du PChars zurückbekommen willst, muss die aufrufende Funktion den Speicher allokieren und freigeben wenn sie den nicht mehr braucht.

z.B. GetModuleFileName

Meienr Meinung nach kann es auftreten, dass Delphi merkt, dass der lokale String nicht mehr benutzt wird und ihn überschreibt, bzw. dessen Speicher freigibt. Du arbeitest u.U. noch weiter mit diesem String (bzw. nur der Adresse) und es kann ggf crashen.

Oder schreibt ihr auch so geniale Funktionen wie:

Delphi-Quellcode:

function blub(a: integer): pinteger;
var s: integer;
begin
  s := a;
  result := @s;
end;

Wäre nett wenn mir mal jemand meine falsche denkweise erklärt.
Danke!

Edit:

Zitat:

Zitat von mkinzler

Zitat:

Zitat von brechi

Nein versuchs so nicht. Funktionen geben keine PChars zurück. Nimm nen String oder packs als Parameter rein und lass die Aufrufende Funktion den Speicher allokieren.

Funktionen in Dlls schon!

Was hat ein allgemeines Stack/Speicher/Addressproblem mit Dlls zu tun. Da wäre das genau so falsch (meiner Auffassung nach)


Edit2:
wer es testen will (Aufruf mit dem wort 'lol')

Rückabe: lol

Delphi-Quellcode:

var
  meinString: String;
function aufreg(meinParameter: PChar): PChar;
begin
   meinString := meinParameter;
   result := PChar(meinString);
end;

Rückgabe: lo

Delphi-Quellcode:

function aufreg(meinParameter: PChar): PChar;
var
  meinString: String;
begin
   meinString := meinParameter;
   result := PChar(meinString);
end;

[Muetze1]

Brechi hast vollkommen Recht. Es ist immer eine temporäre PChar Konvertierung und die verliert genauso ihre Gültigkeit wie auch die lokale string Variable mit verlassen der Funktion. Der Rückgabewert zeigt auf einen ehemals alloziierte/benutzten Block und von daher ist der Rückgabewert reiner Zufall. Grundlegend wird der Speicher bis zum auslesen des Wertes nicht erneut genutzt, und das ergibt hier den Anschein der Gültigkeit.

[Dezipaitor]

also GetMem benutzen.

[Muetze1]

Wie denn? In der DLL mit dem Speichermanager alloziieren und in der App mit deren Speichermanager wieder freigeben? Naja, ich sage dir jetzt schon, der eine weiss vom anderen nichts. Ausnahme: sharemem, aber dann kannste auch gleich Strings übergeben. Ich empfehle die schon zuvor genannte Methode wie es auch schon die WinAPI erfolgreich seit ein paar Jahren macht: App erzeugt einen Buffer und übergibt ihn. Siehe auch Luckies Tutorial dazu...

[Dezipaitor]

wenn die App den Buffer erzeugt, dann muss man auch erstmal wissen wie groß der Buffer sein soll.
GetTokenInformation macht das z.B. so.

[Muetze1]

Zitat:

Zitat von Dezipaitor

wenn die App den Buffer erzeugt, dann muss man auch erstmal wissen wie groß der Buffer sein soll.
GetTokenInformation macht das z.B. so.

Siehe WinAPI: Entweder einen Rückgabewert definieren der darauf hinweist, dass der Puffer zu klein ist oder bei der Übergabe von NIL als PChar wird die benötigte Länge zurück geliefert. Ganz einfach und simple...

[brechi]

@ThE_-_BliZZarD:
Ich hoffe du beachtest die Einwände von Thomas und mir. Du hast vielleicht dein Problem kurzzeitig für deinen Beispielparameter gelöst. Die Lösung mit dem #0 ist einfach nur gefrickel und absolut unsicher. Wunder dich nicht wenn dein programm irgendwann mal einfach crashed.

Benutze einen String als Rückgabewert. Das geht auch in dlls, dafür musst du dann aber als erste unit sharemem benutzen. Ansonsten kann das selbe Verhalten auftreten (manchmal gehts und manchmal nicht).

Oder du benutzt den WinAPI Ansatz wenn du unbedingt einen PChar benutzen willst. Alles andere ist programmiertechnisch unsauber und nicht zu empfehlen. Auch wenn es nun den Anschein hat es funktioniert.

Ich hoffe für alle die mal das selbe Problem haben, dass sie diesen Thread bis zum Ende lesen.

[ThE_-_BliZZarD]

Ich muss mich dem anschließen, es funktioniert nicht mehr. Also bis zurück in das Mutterprog hats mein Wert geschafft, aber dann ist Ende..^^

Ich hatte irgendwo schon ein Sourcebeispiel für eine Implementation ala GetModuleFileName() gesehn, leider finde ich sie nicht mehr :roll:
Hoffe ihr könnt mir nochmal verzeihen und ein gaaanz kurzes Stück Beispielcode machen :-/ Denn, ich habe leider bisher noch nie selber Speicher angefordert/beschrieben geschweige denn wieder freigegeben..

Thx in advance,

BliZZarD

[Dax]

Delphi-Quellcode:

function PCharDLLFunktion(str: PChar): Integer;
var s: String;
begin
  s := StringDLLFunktion;
  if str = nil then
    Result := Length(s)
  else 
  begin
    try
      Move(s[1], str^, Length(s));
      Result := -1; //Success
    except
      Result := -2; //Failure
    end;
  end;
end;


function NichtDLLFunktion: String;
begin
  SetLength(Result, PCharDLLFunktion(nil));
  if PCharDLLFunktion(@Result[1]) <> -1 then
    MessageBox('Fehler');
end;

// Oder so ähnlich

[ThE_-_BliZZarD]

hmm.. warum wurde dort jetzt nichts mit Speicher allozieren/freigeben usw gemacht?
Oder reicht das für meine Zwecke schon.

(man ist mir die Frage peinlich...)



Allllllerdings, ich glaube das Problem behebt sich selbsttätig.

Ich muss einer anderen Funktion in der DLL einen Record übergeben, der jede Menge kram enthält, und der soll in der DLL-Funktion geändert/erweitern werden und dann wieder zum Mutterprogramm zurückgegeben werden.. Dafür brauch ich ShareMem, oder?

Und wenn ja.. dann kann ich ja auch gleich Strings verwenden, ne?

Muss ich irgendwas beachten wenn ich ShareMem einsetze?
Dazu 2 Fragen:
1. Wie kann ich sicherstellen, das die für ShareMem benötigten Bibliotheken (welche DLL's sind das?) auch beim Anwender vorhanden sind? Beim Start des Programms aus einer Resource extrahieren hilft ja nicht, da die DLL's ja schon beim Start geladen werden..
2. Wie muss ich den Record übergeben, damit er im Unterprogramm geändert werden kann und diese Werte auch erhalten bleiben? Normal mit

Delphi-Quellcode:

function DLLs_nerven_irgendwie(var MyKnoten: TKnotenFeld): Integer;

?? Oder gibts da irgendwas special-artiges?^^

Danke leute,

BliZZarD

[Progman]

ShareMem muss als erste Unit in der dpr-Datei stehen, und wenn du die Anwendung weitergibst, musst du die Borlandmm.dll mitgeben.

[Whookie]

1: Ja über SetLength wird Speicher reserviert, damit funktioniert obiges Beispiel

2: Das hängt ganz von deinem Record ab, denn es keiner Größenveränderung bedarf, dann funktioniert dein Beispiel bereits (mit Var übergibst du im Prinzip einen Pointer auf dein Record).