D2010 Char-AnsiChar Problem

[Thorben86]

Hi, habe hier ein kleines Problem mit einer JEDI-Unit (JvVCLUtils) und der neuen Typendeklaration von 2009/2010.

Delphi-Quellcode:

function AnsiUpperFirstChar(const S: string): string;
var
  Temp: string[1];
begin
  Result := AnsiLowerCase(S);
  if S <> '' then
  begin
    Temp := Result[1];
    Temp := AnsiUpperCase(Temp);
    Result[1] := Temp[1]; <--- Fehler
  end;
end;

Fehlermeldung: [DCC Fehler] JvVCLUtils.pas(2256): E2010 Inkompatible Typen: 'Char' und 'AnsiChar'
Ich weis jetzt allerdings nicht, wie ich hier das ganze richtig deklarieren muss.
Dabei ist es eigentlich die aktuelle Version, die schon kompatibel sein sollte.

Hoffe mir kann wer nen Tipp geben.

Gruß
Thorben

[mkinzler]

Mach aus string AnsiString
Oder besser besorge dir eine neue Version der Unit

[Bernhard Geyer]

Einfach etwas umbauen (ungetestet):

Delphi-Quellcode:

function AnsiUpperFirstChar(const S: string): string;
begin
  if S <> '' then
    result = AnsiUpperCase(Copy(S, 1, 1)) + AnsiLowerCase(Copy(S, 2, Length(S)));
  else
    result = '';
end;

[Stevie]

Die unit ist schon seit geraumer Zeit nicht mehr Teil der JCL (bzw liegt im Achive Verzeichnis).
Ich würde mal die ganze Library auf aktuellen Stand bringen sofern möglich.

[himitsu]

Delphi-Quellcode:

function AnsiUpperFirstChar(const S: string): string;
var
  Temp: string;  // <<<<<
begin
  Result := AnsiLowerCase(S);
  if S <> '' then
  begin
    Temp := Result[1];
    Temp := AnsiUpperCase(Temp);
    Result[1] := Temp[1];
  end;
end;

String[x] ist und bleibt, auch weiterhin unter D2009/D2010, ein ShortString und ein ShortString ist quasi die "alte" Version eines AnsiString, mit fester Speicherlänge.

[Stevie]

Zitat:

Zitat von himitsu

Delphi-Quellcode:

function AnsiUpperFirstChar(const S: string): string;
var
  Temp: string;  // <<<<<
begin
  Result := AnsiLowerCase(S);
  if S <> '' then
  begin
    Temp := Result[1];
    Temp := AnsiUpperCase(Temp);
    Result[1] := Temp[1];
  end;
end;

String[x] ist und bleibt, auch weiterhin unter D2009/D2010, ein ShortString und ein ShortString ist quasi die "alte" Version eines AnsiString, mit fester Speicherlänge.

Auch damit wirst du keine Freude haben, wenn mal Umlaute oder anderssprachige Zeichen am Wortanfang stehen. Besser wäre:

Delphi-Quellcode:

uses
  Character;

function UpperFirstChar(const s: string): string;
var
  Temp: Char;
begin
  Result := ToLower(s);
  if S <> '' then
  begin
    Temp := Result[1];
    Temp := ToUpper(Temp);
    Result[1] := Temp;
  end;
end;

[himitsu]

Solange du nicht gerade die AnsiStrings-Unit (oder wie die heißt) eingebunden ist, dann ist AnsiLowerCase eigentlich eine WideString-Version und sollte keine Probleme mit Umlauten oder sonstwas bekommen.

Das ist "leider" eine der schwachsinnigen/unverständlichen versuche seitens Emba, um Codeumstellungen auf Unicode zu erleichtern.

[Stevie]

Zitat:

Zitat von himitsu

Solange du nicht gerade die AnsiStrings-Unit (oder wie die heißt) eingebunden ist, dann ist AnsiLowerCase eigentlich eine WideString-Version und sollte keine Probleme mit Umlauten oder sonstwas bekommen.

Bei Umlauten hast du wahrscheinlich recht, aber bei anderen Sprachen ist das nicht unbedingt richtig.
AnsiLowerCase und AnsiUpperCase benutzen die API Funktionen CharLowerBuff und CharUpperBuff. Die Methoden aus der Characters Unit benutzen LCMapString.

Zitat:

Zitat von msdn

Remarks

Note that CharLowerBuff always maps uppercase I to lowercase I ("i"), even when the current language is Turkish or Azeri. If you need a function that is linguistically sensitive in this respect, call LCMapString.

Gut, wahrscheinlich brauchst du das nicht in deiner Anwendung - ich wollte nur mal darauf hinweisen.
Außerdem ist die Verwendung einer Funktion die AnsiWhatever heißt, aber eigentlich Unicode ist imho einfach nur :wall:

[himitsu]

LCMapString ... achso, na dann isses was Anderes

Zitat:

Zitat von Stevie

Außerdem ist die Verwendung einer Funktion die AnsiWhatever heißt, aber eigentlich Unicode ist imho einfach nur :wall:

Joar, für neue Programme ist das vollkommen schwachsinnig ... neue Programme würde ich da eher mit WideIrgendwas schreiben, aber es gibt ja (standardmäßig) nur AnsiIrgendwas.

Und bei der Umstellung eines Programmes einfach mal alle Ansi durch Weide zu ersetzen wäre nun wirklich kein sooooooo großer Aufwand gewesen, alsdas Emba hier wirklich hätte unbedingt sowas berbrocken hätte müssen, dazumal der Compiler eh an entsprechenden Stellen 'ne Warnung ausgegeben würde.

PS: Nett ist es ja, wenn man dann wirklich mal die AnsiVersion für einen AnsiString benötigt ... denn leider wurden diese Funktionen nicht als Ansi/Wide überladen.