FreeMem D2009 und FastMM

[EWeiss]

Was läuft hier schief das ich ein riesen log von FastMM bekomme?

Delphi-Quellcode:

function ListGetText(hList: HWND; Item: Integer): PWideChar;
var
  sItem: PWideChar;
  nLEN : Integer;
begin
    if Item > 0 then
       dec(Item);

    nLEN := SendMessage(hList, LB_GETTEXTLEN, Item, 0) + 1;
    sItem := AllocMem(nLEN);
    SendMessage(hList, LB_GETTEXT, Item, integer(sItem));

    Result := sItem;
    FreeMem(sItem, nLEN);

end;

Ist mir unbegreiflich.
Habe exakt 108 Zeichen und am Mauszeiger (ToolTip) wird der exakte pfad bis jpg angezeigt.
FastMM zeigt aber mehr zeichen hinter JPG an als ich beim Debuggen zu sehen bekomme.
Sollte eigentlich korrekt sein.

gruss

[FredlFesl]

Du gibst sItem frei, obwohl es noch gebraucht wird.

Delphi-Quellcode:

function ListGetText(hList: HWND; Item: Integer): PWideChar;
...
begin
    ...
    Result := sItem;
    FreeMem(sItem, nLEN); // <<<--------- Das kann nicht gut gehen

end;

Gib einen WideString zurück.

[himitsu]

Am Einfachsten gleich direkt in den WideString reinschreiben.

Delphi-Quellcode:

function ListGetText(hList: HWND; Item: Integer): WideString;
begin
    if Item > 0 then
       dec(Item);
    SetLength(Result, SendMessage(hList, LB_GETTEXTLEN, Item, 0));
    SendMessage(hList, LB_GETTEXT, Item, LPARAM(Result));
end;

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1097992)

Am Einfachsten gleich direkt in den WideString reinschreiben.

Delphi-Quellcode:

function ListGetText(hList: HWND; Item: Integer): WideString;
begin
    if Item > 0 then
       dec(Item);
    SetLength(Result, SendMessage(hList, LB_GETTEXTLEN, Item, 0));
    SendMessage(hList, LB_GETTEXT, Item, LPARAM(Result));
end;

Kein Memory allozieren ?
Und Freigeben?

Denn AllocMem benötigt einen pointer.

PS:
Und damit wäre es auch nicht getan denn CopyFile erwartet ein PWideChar!

Delphi-Quellcode:

          Img := SKAERO_CreateImageFromFile(ListGetText(hList, ListItem));
          if Img <> 0 then
          begin
            hImg := cardinal(SKAERO_GetProperty(WinHandle, FORM_Center));
            SKAERO_DisposeImage(hImg);
            CopyFile(ListGetText(hList, ListItem), PWideChar(
              SKAERO_CENTERFORM), False);
            SKAERO_SetProperty(WinHandle, FORM_Center, Img);
            ResizeWindow(WinHandle, 1);
          end;

Das war auch der Grund das ich über PWideChar gegangen bin
um das unnötige hin und her konvertieren zu vermeiden.

Der Fehler ist auf jedenfall weg ..
Danke.

gruss

[jbg]

Noch als Anmerkung:

Zitat:

Zitat von EWeiss (Beitrag 1097983)

sItem := AllocMem(nLEN);

Du weißt aber schon, dass ein PWideChar aus 2 Byte-Zeichen besteht, also nLEN*2 Bytes notwendig sind. Zudem ist in nLEN das abschließende #0 nicht enthalten, also sind (nLEN+1)*2 Bytes notwendig.

[EWeiss]

Zitat:

Zitat von jbg (Beitrag 1098020)

Noch als Anmerkung:

Zitat:

Zitat von EWeiss (Beitrag 1097983)

sItem := AllocMem(nLEN);

Du weißt aber schon, dass ein PWideChar aus 2 Byte-Zeichen besteht, also nLEN*2 Bytes notwendig sind. Zudem ist in nLEN das abschließende #0 nicht enthalten, also sind (nLEN+1)*2 Bytes notwendig.

Ehrlich gesagt Nein.
Aber jetzt bin ich etwas schlauer.

gruss

[himitsu]

CopyFile wäre eh falsch, denn dieses will einen PChar.
CopyFileW wäre für PWideChar.


Mit PWideChar(s) kann man einen PWideChar erstellen, welcher auf einen WideString zeigt. (einfach direkt beim Aufruf der Funktion casten)

PS: PChar, PAnsiChar und PWideChar sind nur Zeiger, welcher auf Speicherbereiche zeigen ... darum auch P ie Pointer.
Wenn deine Funktion also PWideChar zurücliefern soll, dann darfst du den Speicher also nicht freigeben (nicht an dieser Stelle, sondern erst später)


Warum um Himmels Willen prädige ich ständig umsonst, daß man Typen nicht vermischen soll?
AnsiString, PAnsiChar, AnsiChar und AnsiAPI (ala CopyFileA)
WideString/UnicodeString, PWideChar, WideChar und UnicodeAPI (ala CopyFileW)
ODER
String, PChar, Char und dynamischer API (ala CopyFile), welches sich an den jeweiligen Compiler anpaßt, bzw. welches an den Compiler angepaßt ist.

[FredlFesl]

Zitat:

Zitat von EWeiss (Beitrag 1098000)

Zitat:

Zitat von himitsu (Beitrag 1097992)

Delphi-Quellcode:

function ListGetText(hList: HWND; Item: Integer): WideString;
begin
    if Item > 0 then
       dec(Item);
    SetLength(Result, SendMessage(hList, LB_GETTEXTLEN, Item, 0));
    SendMessage(hList, LB_GETTEXT, Item, LPARAM(Result));
end;

Kein Memory allozieren ?
Und Freigeben?

SetLength allokiert den Speicher. Die Freigabe erfolgt über die Referenzzählung der Strings.

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1098081)

CopyFile wäre eh falsch, denn dieses will einen PChar.
CopyFileW wäre für PWideChar.

Und genau das ist der Müll den Embagardo oder wer auch immer verzapft hat.

Siehe!
function CopyFile; external kernel32 name 'CopyFileW'; // << Warum dieser Schwachsinn.
function CopyFileW; external kernel32 name 'CopyFileW';

Wie soll ein normal Sterblicher damit zurecht kommen.
Schießlich esse ich keinen Apfel wenn ich eine Apfelsine gekauft habe. Oder?
Wenn ich schon nur mit Unicode Arbeiten darf dann benötige ich diese Funktion nicht das verwirrt nur.
EntwderOder.

Zitat:

Warum um Himmels Willen prädige ich ständig umsonst, daß man Typen nicht vermischen soll?
AnsiString, PAnsiChar, AnsiChar und AnsiAPI (ala CopyFileA)
WideString/UnicodeString, PWideChar, WideChar und UnicodeAPI (ala CopyFileW)
ODER
String, PChar, Char und dynamischer API (ala CopyFile), welches sich an den jeweiligen Compiler anpaßt, bzw. welches an den Compiler angepaßt ist.

Das sind die feinen Unterschied zwischen einem Programmierer (Studierten) und einen Hobby Programmierer. ;)

Zitat:

prädige = predige!

etwas predigen gesprochen... jemandem immer wieder sagen, wie er sich verhalten soll. ;)

Danke.

gruss

[himitsu]

Zitat:

Zitat von EWeiss (Beitrag 1098109)

Und genau das ist der Müll den Embagardo oder wer auch immer verzapft hat.

Das ist doch richtig so?

Die WinAPI kennt nut CopyFileA und CopyFileW.
Dieses ist beides in Delphi implementiert
und zusätzlich noch das CopyFile, welches an den "StandardString" des verwendeten Compilers angepaßt ist.
PS: Das ist auch in den C-Headern so.

Char, String, PChar und die APIs ala CopyFile sind Weiterleitungen, welche an den Compiler angepaßt sind.


Wenn du also immer nur String, PChar und die dynamischen APIs nutzt, dann paßt sich dieses jeweils an den Compiler an.

Bis Delphi 2007 also Ansi und ab 2009 Unicode.
Alles andere ist fest uns somit überall gleich.

Ersteres nutzt man, wenn man den "aktuellen"Standard möchte
und Letzteres nutzt man, wenn man unbedingt auf ein bestimmtes Format angewiesen ist.


Genau das Gleiche ist mit dem Integer und LongInt,
wobei hier wirklich jemand mist gebaut hat und urplötzlich, beim Umstieg von 32 auf 64 Bit den Integer eingefrohren hat. :wall:

[EWeiss]

Zitat:

Das ist doch richtig so?

Vielleicht denke ich in einer anderen Perspektive..

Bei D2006 wäre es Richtig wenn man
function CopyFileA; external kernel32 name 'CopyFileA'; verwenden würde
function CopyFileW; external kernel32 name 'CopyFileW'; und dieses um Unicode zeichen darzustellen.


function CopyFile; external kernel32 name 'CopyFileW'; wäre dann total überflüssig.

Meine Meinung..
Die Funktionen sind so definiert Doppelt gemoppelt.
Ein cast von einem cast.

So kannst du auch nicht sagen!

Zitat:

CopyFile wäre eh falsch, denn dieses will einen PChar.

Denn es erwartet kein PChar sondern ein PWideChar.
Wäre also beides richtig, wohlgemerkt unter D2009 nicht unter D2006


gruss

[himitsu]

Funktioniert überall und in jedem Delphi und nutzt das, was man standardmäßig in der VCL vorfindet:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: String);
begin
  CopyFile(PChar(Src), PChar(Dest));
end;

CopyFile(PChar(SrcEdit.Text), PChar(DestEdit.Text));

Das ist dagegen überall ANSI und genauso geht es mit dem Unicode,
egal ob Delphi 7 oder Delphi XE:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: AnsiString);
begin
  CopyFileA(PAnsiChar(Src), PAnsiChar(Dest));
end;

[EWeiss]

Zitat:

Zitat von himitsu (Beitrag 1098116)

Funktioniert überall und in jedem Delphi und nutzt das, was man standardmäßig in der VCL vorfindet:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: String);
begin
  CopyFile(PChar(Src), PChar(Dest));
end;

CopyFile(PChar(SrcEdit.Text), PChar(DestEdit.Text));

Das ist dagegen überall ANSI und genauso geht es mit dem Unicode,
egal ob Delphi 7 oder Delphi XE:

Delphi-Quellcode:

procedure Kopieren(Src, Dest: AnsiString);
begin
  CopyFileA(PAnsiChar(Src), PAnsiChar(Dest));
end;

Jo ;)
Und Danke für deine Ausführungen.

gruss

[Bernhard Geyer]

Zitat:

Zitat von EWeiss (Beitrag 1098109)

Und genau das ist der Müll den Embagardo oder wer auch immer verzapft hat.

Ist m.E. eine sehr gute Idee das so zu machen.

Zitat:

Zitat von himitsu (Beitrag 1098112)

Genau das Gleiche ist mit dem Integer und LongInt,
wobei hier wirklich jemand mist gebaut hat und urplötzlich, beim Umstieg von 32 auf 64 Bit den Integer eingefrohren hat. :wall:

Sun (Java), MS (.NET, Win64). Es wäre m.E. unpraktisch gewesen wenn man nur wegen "bisher ist Size(Int) = Size(Pointer)" das in D64-Bit gemacht hätte obwohl der Rest der Programmierwelt das nicht so macht.

[himitsu]

@Bernhard Geyer:
Ist schon irgendwie klar.

Wobei man das dann als ein Alleinstellunsmerkmal für Delphi hätte werten können.
In der Werbung hieße es dann "Alle anderen machen Mist und nur wir machen es richtig, so wie es früher mal geplant war." :stupid:

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1098192)

Wobei man das dann als ein Alleinstellunsmerkmal für Delphi hätte werten können.
In der Werbung hieße es dann "Alle anderen machen Mist und nur wir machen es richtig, so wie es früher mal geplant war." :stupid:

Und man darf das fluchen Anfangen sobald man irgendwelche C-Header portieren darf bzw. definiert sich dort sein eigenes Int32_64 damit man nicht zig IFDEF's benötigt.

[himitsu]

Wieso?
In C heißen die Typen doch eh alle anders, da braucht man dann nur int und Co. nach LongInt zu übersetzen, anstatt nach Integer. :angle2:

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1098220)

In C heißen die Typen doch eh alle anders

Hast du dir schon mal dir WinAPI Header Dateien angeschaut? Da kommt eine Menge "int" als Parametertyp vor.

Das fängt schon beim CreateWindowEx an.

Code:

HWND WINAPI CreateWindowEx(
  __in      DWORD dwExStyle,
  __in_opt  LPCTSTR lpClassName,
  __in_opt  LPCTSTR lpWindowName,
  __in      DWORD dwStyle,
  __in      int x,
  __in      int y,
  __in      int nWidth,
  __in      int nHeight,
  __in_opt  HWND hWndParent,
  __in_opt  HMENU hMenu,
  __in_opt  HINSTANCE hInstance,
  __in_opt  LPVOID lpParam
);