NextGen und ANSI

[himitsu]

Es ist so aber schwieriger/umständlicher, Funktionen zu sharen, wenn es praktisch keine kompatiblen äquivalenten Typen mehr gibt, mit welchen die Bibliotheksschnittstellen deklariert sind.

Es gab mal Zeiten, da haben Hardwarehersteller auch Pascal-Units für ihre DLLs ausgelefert, aber irgendwie haben viele in den letzten 5-10 Jahren damit aufgehört.
(OK, da liegt es oftmals eher am fehlenden Delphi und daß Delphi ja bekanntlich ausstirbt )

Bei der betreffenden Komponente ist es wirklich so, daß 2005/2006 das letzte Mal was an den Pascaldateien gemacht wurde.
Nur 2011 ist in einer der Dateien noch schnell ein Kommentar reingekommen "Achtung, bei XE muß PChar in PAnsiChar geändert werden".
Und ansonsten stellen die C++-Entwickler die noch Headerdateien ihrer DLLs vorallem nur für Visual Stutio (C/C++) bereit, wobei selbst ein halbwegs aktuelles Visual Basic dabei ist.
Die Unterstüzen ja fast alles
* Visual Studio, Borland C++ Builder, Embarcadero C++ Builder, eMbedded Visual C++ 4, Visual Studio 2005/2008/2012, GCC (Linux/Mac OS X), Xcode
* Windows XP/Vista/7/8, Windows CE, Linux, Mac OS X, Android
* 32 und 64 Bit
nur Unicode-Only ist irgendwie sonst fast nirgendwo anzutreffen

Bei anderen Firmen war das auch schon zu beobachten.

[mkinzler]

Der String von iOS ist UTF-16 (alternativ UTF-8). Der String unter Android ist auch UTF-16.

Wenn Du trotzdem mit Ansi arbeiten will nimm den "Patch" von Andreas.

Wenn Du den Hersteller zu einer Meinungsänderung bewegen willst ist die DP auch der falsche Ort. Beschwer Dich direkt bei den Verantwortlichen ( Marco, David, ...)

[himitsu]

Wir wollten die Dateien dann dem Hersteller geben und da würde ich ungern einen Patch drin lassen wollen.
Welcher auch noch nur für die eine Compilerversion funktioniert. (er kann ja nur DCUs liefern)

[himitsu]

Beispiel an einer kurzen Methode:

Delphi-Quellcode:

procedure FETCP_CheckError(iErrorCode: Integer);
var
  Temp: array[0..255] of AnsiChar;
begin
  if iErrorCode < 0 then
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) < 0 then
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress
    else
      raise Exception.CreateFmt('%s', [iErrorCode, string(Temp)]) at ReturnAddress;;
  end;
end;

Was Delphi früher mal alles automatisch machte, darf man jetzt selber machen.

• Speicher reservieren
• das Ende des PAnsiChar suchen
• den String kopieren und nach Unicode umwandeln

Delphi-Quellcode:

procedure FEUSB_CheckError(iErrorCode: Integer);
var
  Temp: TBytes;
  Len:  Integer;
begin
  if iErrorCode < 0 then begin
    SetLength(Temp, 256);
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) >= 0 then begin
      Len := 0;
      while (Len < 256) and (Temp[Len] <> 0) do
        Inc(Len)
      raise Exception.CreateFmt('%s', [iErrorCode, TEncoding.Default.GetString(Temp, 0, Len)]) at ReturnAddress;  // Default heißt jetzt ANSI, was im Grunde auch besser ist, aber XE kennt es noch nicht
    end else
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress;
  end;
end;

Gut, es ginge bestimmt auch so, aber wer weiß, ob sich TEncoding nicht an der #0 und den "ungültigen" Zeichen verschluckt.
Der statische Record geht auch nicht mehr, da die Pointer-Funktionen vom TEncoding im Strict-Protected versteckt sind und ich keine Lust hatte mir das erst freizuschalten, also alles immer schön in den langsamen Speichermanager, anstatt mal eben schnell auf den Stack.

Delphi-Quellcode:

procedure FEUSB_CheckError(iErrorCode: Integer);
var
  Temp: TBytes;
begin
  if iErrorCode < 0 then begin
    SetLength(Temp, 256);
    if FEUSB_GetErrorText(iErrorCode, @Temp[0]) >= 0 then 
      raise Exception.CreateFmt('%s', [iErrorCode, PChar(TEncoding.Default.GetString(Temp))]) at ReturnAddress;
    else
      raise Exception.CreateFmt('FEUSB: unknown error code %d', [iErrorCode]) at ReturnAddress;
  end;
end;

Ich dachte mal, es würde mit der Zeit leichter werden, da die RTL Einem immer mehr Arbeit abnimmt.

Oder hab ich was übersehn?