string ein Alias für UnicodeString

[EWeiss]

Zitat:

Hinweis: In RAD Studio ist string ein Alias für UnicodeString.

Also im Klartext..
Kann ich alle WideString mit String ersetzen (Unter D2010 32Bit und DCE 64Bit? ) oder gibt es Konvertierungsprobleme in welcher Art auch immer?

Zitat:

Sie sollten UnicodeString anstelle von WideString verwenden.

Was denn nun?
UnicodeString oder String wenn String doch das gleiche sein soll wie UnicodeString

Die Beschreibungen sind manchmal wirklich unverständlich.

Warum die Frage..
Hatte gestern einen Absturz nur bei einer Zuweisung eines ToolTip mit WideString. (Ausschließlich 64Bit, unter 32Bit war das kein Problem)
Nach der Änderung der Variable auf string war das Problem behoben.
Um so etwas in der Zukunft zu vermeiden möchte ich alle WideString nach string umlegen. (Nur was habe ich dann zu erwarten? )

gruss

[Fritzew]

Ja kannst Du.
Allerdings mit einer Einschränkung. Immer wenn Du Delphi verlässt also z.B ein Interface zu COM,
oder Eine Dll lass es auf Widestring.
Alles was innerhalb von Delphi läuft sollte kein Problem darstellen.

[EWeiss]

Zitat:

oder Eine Dll lass es auf Widestring.

Es geht um eine DLL (Delphi) dort hatte ich das Problem mit dem ToolTip.
Also so lassen wie es ist.

Danke!

PS:

Zitat:

Alles was innerhalb von Delphi läuft sollte kein Problem darstellen.

Die Win32Api Funktionen bzw.. System DLL's werden ja nicht in Delphi geschrieben wenn ich diese mit string anstelle WideString (wenn verlangt aufrufe) kracht es?
Also die Frage ist wann verlasse ich Delphi..

gruss

[Fritzew]

Zitat:

Die Win32Api Funktionen bzw.. System DLL's werden ja nicht in Delphi geschrieben wenn ich diese mit string anstelle WideString (wenn verlangt aufrufe) kracht es?
Also die Frage ist wann verlasse ich Delphi.

Bei der WinApi geht es in den meisten Fällen um PChar.......
Widestring würde ich da nur benutzen wenn es auf der API Seite verlangt wird als BSTR und consorted auf der C, C++ Seite.
Aber ohne konkretes Beispiel kann man da nicht mehr sagen......

[EWeiss]

Ich habe es mal versucht..
Das geht leider nicht nach der ändern alles auf String kracht die Anwendung ;)

War ein test dachte könnte mir damit solche Probleme wie mit dem ToolTip dadurch ersparen.

gruss

[TiGü]

Zitat:

Zitat von EWeiss (Beitrag 1419636)

Also die Frage ist wann verlasse ich Delphi..

Als Daumenregel: Immer dann, wenn du nicht in die konkrete Implementierung einer Funktion gucken kannst (Strg+Linksklick).
Du arbeitest doch viel direkt mit Windows-Funktionen, um deine GUIs aufzubauen.
Du kennst ja die Funktion

Delphi-Quellcode:

function GetDC(hWnd: HWND): HDC; stdcall;

aus der Windows-Unit.
Da kannst du nicht reingucken, weil sie extern in der user32.dll von Windows definiert ist.

Delphi-Quellcode:

function GetDC; external user32 name 'GetDC';

[EWeiss]

Danke.

gruss

[KodeZwerg]

Zitat:

Zitat von EWeiss (Beitrag 1419636)

Also die Frage ist wann verlasse ich Delphi..

Ich hoffe nie :lol:

[EWeiss]

Muss nochmal nachhaken..

Wenn string ein Alias für UnicodeString ist warum bekomme ich dann einen Speicherleck.

bsp.
Mein Hint ist ein string die Funktion die den Hint füllen soll gibt WideString zurück.
Warum wird mir jetzt ein Speicherleck angezeigt wenn beides doch eigentlich das gleiche sein soll ?
WideString und string = UnicodeString (D2010)

Oder bin ich heute einfach nur blöd!
Den Widestring bekomme ich einfach nicht nach string konvertiert andauernd Speicherlecks.

gruss

[mkinzler]

UnicodeString ist ein (von der Delphi RTL) verwalteter Typ, WideString nicht.

[EWeiss]

Zitat:

Zitat von mkinzler (Beitrag 1419724)

UnicodeString ist ein (von der Delphi RTL) verwalteter Typ, WideString nicht.

Bekomme ihn nicht konvertiert nach string kann machen was ich will.
Ka was du mir damit sagen willst. ;)

gruss

[Uwe Raabe]

In Delphi ist

Delphi-Quellcode:

string

ein managed type, um dessen Freigabe man sich nicht kümmern muss. UnicodeString ist nur ein Alias für

Delphi-Quellcode:

string

, so in der Art:

Delphi-Quellcode:

type
  UnicodeString = string;

Ein

Delphi-Quellcode:

WideString

ist ein non-managed type, um dessen Freigabe sich jemand kümmern muss. Eine Konvertierung von

Delphi-Quellcode:

WideString

nach

Delphi-Quellcode:

string

erzeugt einen neuen

Delphi-Quellcode:

string

, entbindet aber nicht von der Pflicht zur Freigabe des

Delphi-Quellcode:

WideString

.

[EWeiss]

Danke.
Er meldet mir hier einen Speicherleck.

Delphi-Quellcode:

FAudioSessionInfo.DisplayName := string(GetVerInfo(FileName));

DisplayName = string
GetVerInfo = WideString

Wenn ich jetzt den WideString von GetVerInfo an DisplayName übergebe wie soll ich ihn dann freigeben er wird im weiteren verlauf benötigt.
Hmmm....

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1419729)

Er meldet mir hier einen Speicherleck.

Das ist nachvollziehbar.

Delphi-Quellcode:

GetVerInfo

liefert einen

Delphi-Quellcode:

WideString

zurück, um dessen Freigabe du dich kümmern musst. Die Konvertierung nach

Delphi-Quellcode:

string

erzeugt einen neuen

Delphi-Quellcode:

string

, lässt aber den Speicherbereich des

Delphi-Quellcode:

WideString

unangetastet. Da du an den

Delphi-Quellcode:

WideString

so aber nicht mehr herankommst, kannst du ihn auch nicht freigeben. Daher entsteht hier ein Speicherleck.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1419730)

Zitat:

Zitat von EWeiss (Beitrag 1419729)

Er meldet mir hier einen Speicherleck.

Das ist nachvollziehbar.

Delphi-Quellcode:

GetVerInfo

liefert einen

Delphi-Quellcode:

WideString

zurück, um dessen Freigabe du dich kümmern musst. Die Konvertierung nach

Delphi-Quellcode:

string

erzeugt einen neuen

Delphi-Quellcode:

string

, lässt aber den Speicherbereich des

Delphi-Quellcode:

WideString

unangetastet. Da du an den

Delphi-Quellcode:

WideString

so aber nicht mehr herankommst, kannst du ihn auch nicht freigeben. Daher entsteht hier ein Speicherleck.

Ist also nicht zu beheben?

gruss

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1419731)

Ist also nicht zu beheben?

Nein, solange du nicht den Rückgabetyp von GetVerInfo in string ändern kannst.

Ein WideString ist einfach nur ein Pointer auf ein WideChar-Array mit einem Längenbyte davor: http://docwiki.embarcadero.com/RADSt...deString-Typen

Bei einem string gibt es viel mehr Informationen: http://docwiki.embarcadero.com/RADSt...e_String-Typen

Delphi kann ja nicht einfach ein paar Daten vor dem WideString in den Speicher schreiben, um die fehlenden Informationen herzuzaubern.

[EWeiss]

Danke Uwe muss mal sehen wie ich das gelöst bekomme.

gruss

[TiGü]

Woher kommt denn diese Funktion GetVerInfo?
Sie scheint weder Bestandteil der Windows-API noch zum Delphi-Framework zugehörig zu sein.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1419738)

Woher kommt denn diese Funktion GetVerInfo?
Sie scheint weder Bestandteil der Windows-API noch zum Delphi-Framework zugehörig zu sein.

Von hier!
http://www.delphidabbler.com/articles.php?id=20

http://www.delphidabbler.com/articles?article=20#demo
http://www.delphidabbler.com/download?id=art-20

Ich habe es gelöst musste nur an der untersten Ebene anfangen zu suchen und dort die Datentypen nach WideString umlegen.
Da mir EurekaLog und ReportMemoryLeaksOnShutdown nichts mehr melden sollte es in Ordnung sein.

gruss

[TiGü]

Also in der Unit UVerInfoRoutines.pas aus dem article-20-demo.zip ist das wie folgt definiert:

Delphi-Quellcode:

{
GetVerInfo:
  Thin wrapper around API routine. Loads version information for a given file
  into a buffer. Raises exception if version information can't be read.
}
procedure GetVerInfo(const FileName: string; const Size: Integer;
  const Buffer: Pointer);

Delphi-Quellcode:

procedure GetVerInfo(const FileName: string; const Size: Integer;
  const Buffer: Pointer);
begin
  if not GetFileVersionInfo(PChar(FileName), 0, Size, Buffer) then
    raise Exception.Create('Can''t load version information');
end;

Das ist doch gänzlich was anderes als was du weiter oben im Thread verwendest.
Da scheint es eine function anstatt procedure zu sein.
Auch von WideString ist nichts zu lesen.

[EWeiss]

Zitat:

Das ist doch gänzlich was anderes als was du weiter oben im Thread verwendest.

Nun ja etwas muss man schon selber machen..

Delphi-Quellcode:

function GetVerInfo(FileName: string): WideString;
var
  VI: TVerInfo;
  TransIdx: integer;
  Trans: string;
  StrIdx: integer;
  StrName: string;
begin
  VI := TVerInfo.Create(FileName);
  try
    if VI.HasVerInfo then
    begin
      for TransIdx := 0 to Pred(VI.TranslationCount) do
      begin
        Trans := VI.Translations[TransIdx];

        // display all standard strings
        for StrIdx := Low(cStrNames) to High(cStrNames) do
        begin
          StrName := cStrNames[StrIdx];
          if StrName = 'FileDescription' then
          begin
            Result := VI.Strings[Trans, StrName];
            Break;
          end;
        end;
      end;
    end
    else
      Result := '';
  finally
    VI.free;
  end;
end;

Siehe..

Delphi-Quellcode:

Result := VI.Strings[Trans, StrName];

Delphi-Quellcode:

property Strings[const Trans, Name: string]: string read GetString;

Delphi-Quellcode:

function TVerInfo.GetString(const Trans, Name: string): string;
begin
  Assert(fHasVerInfo);
  Result := GetVerInfoStr(fVerInfo, Trans, Name); // <<< hier der Part 
end;

Delphi-Quellcode:

function GetVerInfoStr(const Buffer: Pointer;
  const Trans, StrName: string): string;

gruss

[TiGü]

Kannst du vernünftig und logisch schlüssig erklären, warum du an der Stelle als Result-Typ WideString nimmst?
Warum benennst du deine eigene Funktion exakt gleich zu einer Funktion aus einen fremden verwendeten Quelltext?
Du machst dir doch selber das Leben schwer.

[EWeiss]

Zitat:

Kannst du vernünftig und logisch schlüssig erklären, warum du an der Stelle als Result-Typ WideString nimmst?

Weil meine Funktion innerhalb meiner DLL WideString benötigt.

Zitat:

Warum benennst du deine eigene Funktion exakt gleich zu einer Funktion aus einen fremden verwendeten Quelltext?

Wüsste jetzt nicht was da gleich ist.
GetVerInfo <> GetVerInfoStr

Die andere GetVerInfo wird gar nicht aufgerufen bzw. verwendet.

Aber.. Das Thema ist eigentlich erledigt weil ich es innerhalb meiner DLL gefixt habe. ;)

gruss

[TiGü]

Innerhalb deines eigenen Moduls besteht doch gar keine Notwendigkeit auf WideString zu gehen.

[EWeiss]

Zitat:

Zitat von TiGü (Beitrag 1419766)

Innerhalb deines eigenen Moduls besteht doch gar keine Notwendigkeit auf WideString zu gehen.

Werde es nochmal gegenprüfen.. kann nichts schaden. Danke.

gruss

[Uwe Raabe]

Keine Ahnung, ob das hier relevant ist, aber vielleicht hilft es ja: Der Shared Memory Manager

Zitat:

Zitat von Der Shared Memory Manager

Wenn eine DLL in Win32 Routinen exportiert, die lange Strings oder dynamische Arrays als Parameter oder als Funktionsergebnis übergeben (entweder direkt oder in Records bzw. Objekten), müssen die DLL und ihre Client-Anwendungen (oder -DLLs) die Unit ShareMem verwenden.

[EWeiss]

Danke für eure Informationen.
Wie ich schon sagte..

Zitat:

Ich habe es gelöst musste nur an der untersten Ebene anfangen zu suchen und dort die Datentypen nach WideString umlegen.
Da mir EurekaLog und ReportMemoryLeaksOnShutdown nichts mehr melden sollte es in Ordnung sein.

Ich habe keine Speicherlecks mehr.
Innerhalb der Anwendung besteht kein Grund mehr WideStrings zu verwenden habe es korrigiert und nochmals auf Speicherlecks geprüft.
Scheint alles IO zu sein wenn man sich denn auf EurekaLog und ReportMemoryLeaksOnShutdown verlassen kann.

gruss

[QuickAndDirty]

Welches war der Stringtyp der von Windows als OLE Objekt verwaltet wurde und weder Freigabe noch Management durch den Delphi Memorymanager oder fastmem brauchte?

[mkinzler]

WideString. Aber nur bei Verwendung von OLE.

[EWeiss]

Ich verwende viele WideStrings innerhalb meiner DLL diese arbeitet aber global mit Interfaces
Mein Fehler war früher das ich nicht wusste das Strings Unicode fähig sind das war der einzige Grund das ich WideString eingebaut habe.
Das jetzt alles umzuschreiben macht am ende mehr kaputt als das es irgendeinen Vorteil bringt, daher lasse ich es so.

Habe bisher hier keine Probleme. (Abgesehen vom ToolTip warum auch immer 64Bit)
Ja jetzt kommt der Aufschrei.. Nein lieber PWideChar verwenden. :) Ist aber auch kein Allheilmittel

gruss