RPC und Delphi 2009

[alphaflight83]

Tag auch,

ich hätte auch mal wieder ein Problem.
Ich hatte ein Delphi 7 Programm, das einige XML-RPC Funktionen verwendet hat.
( aus xmlrpctypes, xmlrpcclient)
RpcCaller : TRpcCaller;
RpcFunction : IRpcFunction;
RpcResult : IRpcResult;

Nun läuft die Version 2.0 von XML-RPC nicht mehr mit Delphi 2009 auf die ich nun umstelle,
was mich zu der Frage bringt, welche Vorgehensweise hier am sinnvollsten ist:
1. Auf andere Komponenten wechseln und wenn ja welche, oder
2. Die XML-RPC versuchen in Gang zu bringen

Wäre schön, wenn mir jemand weiterhelfen könnte.

Gruß

[mkinzler]

Zitat:

Nun läuft die Version 2.0 von XML-RPC nicht mehr mit Delphi 2009 auf die ich nun umstelle,

Wie äussert sich das?

[alphaflight83]

Nunja, wenn ich die XML-RPC mit D2009 verwenden will nehme ich an, dass ich die auch damit kompilieren muss.
Beim kompiliervorgang kommen dann aber zahlreiche Fehler, die wohl mit der Umstellung auf Utf8 zusammenhängen.
Jetzt gings mir eben darum, ob es hier eine Aktualisierung gibt, ob das mittlerweile sowieso alles anders gemacht wird,
oder ob ich mich einfach zu dumm anstelle.

[mkinzler]

Dann zeig doch mal die Fehlermeldungen

[mjustin]

Zitat von alphaflight83:

Tag auch,

ich hätte auch mal wieder ein Problem.
Ich hatte ein Delphi 7 Programm, das einige XML-RPC Funktionen verwendet hat.
( aus xmlrpctypes, xmlrpcclient)
RpcCaller : TRpcCaller;
RpcFunction : IRpcFunction;
RpcResult : IRpcResult;

Nun läuft die Version 2.0 von XML-RPC nicht mehr mit Delphi 2009 auf die ich nun umstelle,
was mich zu der Frage bringt, welche Vorgehensweise hier am sinnvollsten ist:
1. Auf andere Komponenten wechseln und wenn ja welche, oder
2. Die XML-RPC versuchen in Gang zu bringen

Wäre schön, wenn mir jemand weiterhelfen könnte.

Gruß

Hier sind zwei Kandidaten:

REMObjects SDK- http://www.remobjects.com/ro.aspx
Pros:
Free .NET client (great for calling Delphi from ASP)
SOAP server
FreePascal support
XMLRPC

RealThinClient- http://www.realthinclient.com
Pros:
Extemely flexible
FreePascal support
XMLRPC

(zitiert aus: https://forums.codegear.com/message....essageID=84775)

[alphaflight83]

Nuja, zum Beispiel tritt in dieser Funktion ein E2010: Inkompatible Typen - Fehler auf.

Delphi-Quellcode:

FUNCTION  Utf8ToAnsi (Source : STRING; UnknownChar : CHAR = '¿') : ANSISTRING; // <- Result: AnsiString
          (* Converts the given UTF-8 String to Windows ANSI (Win-1252).
             If a character can not be converted, the "UnknownChar" is inserted. *)
VAR
  SourceLen : INTEGER;  // Length of Source string
  I, K      : INTEGER;
  A         : BYTE;     // Current ANSI character value
  U         : WORD;
  Ch        : CHAR;     // Dest char
  Len       : INTEGER;  // Current real length of "Result" string
BEGIN
  SourceLen := Length (Source);
  SetLength (Result, SourceLen);   // Enough room to live
  Len := 0;
  I   := 1;
  WHILE I <= SourceLen DO BEGIN
    A := ORD (Source [I]);
    IF A < $80 THEN BEGIN                                               // Range $0000..$007F
      INC (Len);
      Result [Len] := Source [I]; // ---> Fehlermeldung: E2010: Inkompatible Typen: AnsiChar und Char (Source : String, Result : AnsiString)
      INC (I);
      END
    ELSE BEGIN                                                          // Determine U, Inc I
      IF (A AND $E0 = $C0) AND (I < SourceLen) THEN BEGIN               // Range $0080..$07FF
        U := (WORD (A AND $1F) SHL 6) OR (ORD (Source [I+1]) AND $3F);
        INC (I, 2);
        END
      ELSE IF (A AND $F0 = $E0) AND (I < SourceLen-1) THEN BEGIN        // Range $0800..$FFFF
        U := (WORD (A AND $0F) SHL 12) OR
             (WORD (ORD (Source [I+1]) AND $3F) SHL 6) OR
             (      ORD (Source [I+2]) AND $3F);
        INC (I, 3);
        END
      ELSE BEGIN                                                        // Unknown/unsupported
        INC (I);
        FOR K := 7 DOWNTO 0 DO
          IF A AND (1 SHL K) = 0 THEN BEGIN
            INC (I, (A SHR (K+1))-1);
            BREAK;
            END;
        U := WIN1252_UNICODE [ORD (UnknownChar)];
        END;
      Ch := UnknownChar;                                                // Retrieve ANSI char
      FOR A := $00 TO $FF DO
        IF WIN1252_UNICODE [A] = U THEN BEGIN
          Ch := CHR (A);
          BREAK;
          END;
      INC (Len);
      Result [Len] := Ch; // ---> Fehlermeldung: E2010: Inkompatible Typen: AnsiChar und Char (Ch : Char , Result : AnsiString)
      END;
    END;
  SetLength (Result, Len);
END;

Hier stellt sich nun die Frage, ob man die Funktionen (gibts auch rückwärts, die ist aber fehlerfrei)
überhaupt noch benötigt.
Hab mich mit dem Code noch nicht eingehend befasst, wollte das eben auch möglichst vermeiden.
Aber anscheinend sind alle Äpfel sauer, in die ich hier beissen kann.

@mjustin: Danke mal für die Alternativen
Allerdings kommen beide für mich nicht in Frage, da der Einsatz sich auf einige wenige Zugriffe beschränkt und der Preis somit
kaum zu rechtfertigen ist.

[mkinzler]

String / Char -> Ansistring/AnsiChar

[alphaflight83]

Wenn das alles wäre, wäre mir das schon klar. Mir geht es aber eher darum ob das Gesamtkonzept in dieser Form noch funktioniert.
Wenn ich einen Char hier mit einem AnsiChar ersetze, zieht sich das wie ein Rattenschwanz durch den ganzen Code.
Der Aufwand den kompletten XML-RPC Code zu durchforsten wird dann doch relativ groß.

[mjustin]

Zitat von alphaflight83:

Wenn das alles wäre, wäre mir das schon klar. Mir geht es aber eher darum ob das Gesamtkonzept in dieser Form noch funktioniert.
Wenn ich einen Char hier mit einem AnsiChar ersetze, zieht sich das wie ein Rattenschwanz durch den ganzen Code.
Der Aufwand den kompletten XML-RPC Code zu durchforsten wird dann doch relativ groß.

Alternativ könnte man auch AnsiString überall mit "string" ersetzen, ausser da, wo ein UTf-8 String benötigt wird. Den kann man z.B. mit Utf8Encode / Utf8Decode konvertieren, und die gepostete Funktion ist damit ersetzbar.

Aber das mit dem Rattenschwanz stimmt schon ...

[alphaflight83]

Okay, hab mich jetzt mal an den Rattenschwanz gewagt und fröhlich Ansis erschlagen.
Hänge nun aber an einem Punkt in der Datei XmlRpcClient an dem die Funktion

Delphi-Quellcode:

HashMessageDigest := TIdHashMessageDigest5.Create;
  try
    { determine the md5 digest hash of the request }
    Hash := Hash128AsHex(HashMessageDigest.HashValue(XmlRequest)); // <-

aufgerufen wird.
Jetzt bin ich mir nicht ganz sicher ob ich mich hier schon verrant habe.
Eine Methode Hashvalue konnte ich in HashMessageDigest samt aller Mutter, Grußmutter ... -Klassen nicht finden.
Mit allen anderen vorhandenen Methoden hauts auch nicht hin.
Hash128ToHex will einen Übergabewert vom Typ T4x4LongWordRecord.
Aus Indy's IdHashMessageDigest: T4x4LongWordRecord = array[0..3] of LongWord; Das einzige Attribut das diesen Typ aufweist ist FState in der Mutterklasse TIdHashMessageDigest4 und liegt protected vor.

Edit: HashValue gibt es allerdings in den Klassen TIdHash16 und TIdHash32 die genau wie die TIdHashMessageDigests von TIdHash erben ...