chr Funktion in Delphi 2009

[roadrunner-S51]

Hallo, bin neu hier, deswegen entschuldigt bitte falls ich hier nicht im richigen Bereich für dieses Thema bin. :oops:

Also ich schreibe gerade meine Bachelor-Arbeit und muss ein Delphiprogramm, erstellt in Turbo Delphi auf Delphi 2009 "umrüsten". Das ist soweit kein großes Problem, außer die Kommunikation über den COM-Port. Dort wird die chr-Funktion verwendet, welche, soviel habe ich nun schon gelernt, statt einem char ein Unicode-Zeichen zurückgibt.

Könnte mir also bitte jemand helfen die folgenden Code-Zeilen funktionsfähig umzubauen? Ich komm da irgendwie nicht auf nen grünen Zweig... :gruebel:

UsedComm[3]:=chr($30+Value);
H:=CreateFile(UsedComm,GENERIC_READ or GENERIC_WRITE, 0,nil,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);

Die Fehlermeldung von Delphi lautet:
[DCC Fehler] HESerial32.pas(104): E2010 Inkompatible Typen: 'AnsiChar' und 'Char'

Hier der Code ringsum das Problem:
var
UsedComm : array[0..12] of ansichar = 'COMx'#0#0;
...
begin
...
if Value<10 then
begin
UsedComm:='COMx'+#0;
UsedComm[3]:=chr($30+Value);
end
else
begin
UsedComm:='\\.\COMx'+#0+#0;
UsedComm[7]:=chr($30+(Value div 10));
UsedComm[8]:=chr($30+(Value mod 10));
end;
end;

Schonmal Danke!

[Neutral General]

Hallo,

Du musst anstatt

Delphi-Quellcode:

chr($30+Value);

folgendes schreiben:

Delphi-Quellcode:

AnsiChar($30+Value);

Übrigens: Um deinen Code kannst du Delphi-Tags machen [.delphi] und [./delphi] (jeweils ohne den Punkt). Dann wird man nicht ganz so blind wenn man versucht deinen Code zu lesen :mrgreen:

[himitsu]

Chr = Char = WideChar (ab Delphi 2009) = AnsiChar (bis Delphi 2007)

Wenn du also explizit AnsiString/AnsiChar verwendest, dann mußt du deinen Wert auch explizit nach AnsiChar casten.

[roadrunner-S51]

Hey das ging ja schnell! Super, Danke!

@NeutralGeneral: Ok, ich werde mich bessern! :wink:

Nun hab ich nur leider das nächste Proglem:
[DCC Fehler] HESerial32.pas(119): E2010 Inkompatible Typen: 'Array' und 'PWideChar'

Der Code dazu:

Delphi-Quellcode:

Result:=GetDefaultCommConfig(@UsedComm[4],CommConfig,i) or
          GetDefaultCommConfig(UsedComm,CommConfig,i);

        H:=CreateFile(UsedComm,GENERIC_READ or GENERIC_WRITE,
                0,nil,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
        H:=CreateFile(UsedComm, GENERIC_READ or GENERIC_WRITE, 0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED, 0);

[mkinzler]

Welche Zeile ist den die 119?

[roadrunner-S51]

Das ist die oberste als

Delphi-Quellcode:

Result:=GetDefaultCommConfig(@UsedComm[4],CommConfig,i) or
          GetDefaultCommConfig(UsedComm,CommConfig,i);

Die folgenden Codezeilen führen aber zur selben Fehlermeldung.

Habe mir gerade überlegt, die Variable UsedComm ist ja offensichtlich ein Feld. Muss ich das irgendwie umkonvertieren?

[mkinzler]

Versuch es mal mit PWideChar(UsedComm[4])

[Neutral General]

Zitat:

Zitat von mkinzler

Versuch es mal mit PWideChar(UsedComm[4])

Das Problem könnte evtl sein, dass UsedComm ein Array of AnsiChar ist. der Cast auf PWideChar wird dann für chinesischen String-Müll sorgen fürchte ich. Eine Idee die ich hätte (aber keine Ahnung obs klappt):

Delphi-Quellcode:

PChar(String(AnsiString(@UsedComm[4])))

Allerdings könnte die Funktion auch einen Ansistring wollen und hat aus "früheren" Zeiten noch "PChar" als Parametertyp definiert. Für diesen Fall müsste mkinzler Recht haben. (Bzw. bei dir fehlt noch ein @ vor dem UsedComm[4]) D.h.:

Delphi-Quellcode:

PChar(@UsedComm[4])

[roadrunner-S51]

Das klappt leider nur bedingt. Nun meckert der Compiler bei dem Code nach dem or, also

Delphi-Quellcode:

Result:=GetDefaultCommConfig(PWideChar(UsedComm[4]),CommConfig,i) or
          GetDefaultCommConfig(UsedComm,CommConfig,i);

Die Fehlermeldung bleibt die gleiche.

Jepp, das ist ein AnsiChar-Feld!

[Neutral General]

Zitat:

Zitat von roadrunner-S51

Das klappt leider nur bedingt. Nun meckert der Compiler bei dem Code nach dem or, also

Delphi-Quellcode:

Result:=GetDefaultCommConfig(PWideChar(UsedComm[4]),CommConfig,i) or
          GetDefaultCommConfig(UsedComm,CommConfig,i);

Die Fehlermeldung bleibt die gleiche.

Jepp, das ist ein AnsiChar-Feld!

Siehe mein Edit obendrüber.

[roadrunner-S51]

Also müsste ich das AnsiChar-Feld UsedComm in einen PWideChar wandeln und alles wäre super?

[Neutral General]

Hallo,

Also du müsstest (wahrscheinlich) den Pointer auf das 5 Element (Index 4) auf einen PWideChar casten:

Delphi-Quellcode:

Result:=GetDefaultCommConfig(PWideChar(@UsedComm[4]),CommConfig,i) or GetDefaultCommConfig(UsedComm,CommConfig,i);

[roadrunner-S51]

Wenn ich das richtig verstehe will der Code aber das ganze Feld übergeben, oder? Das heißt ich müsste alle Elemente casten?

[Neutral General]

Ich weiß ja nicht genau was die Funktion haben will und was in dem Array drin steht.

Aber PWideChar(UsedComm[4]) ist quasi der String ab dem 5. Zeichen.

D.h.

Delphi-Quellcode:

var: S: Array[0..10] of AnsiChar;
begin
  S := 'Hallo Welt'; // Mal vereinfacht geschrieben. Nur zur Verdeutlichung
  PWideChar(@S[4]) ==> 'o Welt'
end;

[roadrunner-S51]

Danke für den Hinweis mit dem @!
Habe den Code nun so geändert:

Delphi-Quellcode:

Result:=GetDefaultCommConfig(PWideChar(@UsedComm[4]),CommConfig,i) or
          GetDefaultCommConfig(PWideChar(@UsedComm[0]),CommConfig,i);

Also müsste im ersten Teil, wie auch im Beipiel von NeutralGeneral das Feld ab dem 5. Element und im zweiten Teil das komplette Feld (ab dem 0. Element) konvertiert werden.

Ich jage das ganze dann nochmal durch den Debugger, mal schauen ob das so passt.

Erstmal danke an alle!
:thumb:

[roadrunner-S51]

Nach ausführlicher Prüfung und einem halben Nervenzusammenbruch habe ich nun den Fehler im Code gefunden. Mein Versuch, das AnsiString-Feld in eine PWideChar zu wandeln, lief einfach nicht so.

Leider besteht das Problem der Konvertierung immernoch und ich weiß leider nur, dass es so

Delphi-Quellcode:

H:=CreateFile(PWideChar(@UsedComm[0]),
    GENERIC_READ or GENERIC_WRITE,
    0,
    nil,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED,
    0);

nicht geht.

Hat jemand eine bessere und vor allem funktionierende Idee?

[mkinzler]

Einfach PAnsiChar verwenden

[Neutral General]

Hattest du es mal mit:

Delphi-Quellcode:

PChar(String(AnsiString(@UsedComm[0])))

versucht?

[roadrunner-S51]

Alles was mein Delphi dazu zu sagen hat ist leider:
[DCC Fataler Fehler] Autofrett.dpr(1): F2084 Interner Fehler: AV0529AB9B-R00000001-0

[Neutral General]

:mrgreen:

Also bei mir compiliert das ohne Probleme. Habe D2009.

Versuch vllt. mal nur:

Delphi-Quellcode:

PChar(String(@UsedComm[0]))

[roadrunner-S51]

Hab meinen PC mal neu gestartet und nun klappts auch mit der Kompilierung. Hatte sicher noch irgendwelchen Datenmüll im Speicher...

So, nun passt alles! :party:

Delphi-Quellcode:

H:=CreateFile(PChar(String(UsedComm)),
    GENERIC_READ or GENERIC_WRITE,
    0,
    nil,
    OPEN_EXISTING,
    FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED,
    0);

Das @ und die Angabe des Feldelementes waren irgendwie störend.

@Neutral General: Dankeschön!!!

[himitsu]

ich weiß nicht wie oft ich das schon runterprädige:
Keine Ansi/Wide/dynamischen Varianten mischen!

CreateFile + PChar (Char / String) - diese sind seit Delphi 2009 Unicode und davor Ansi
CreateFileA + PAnsiChar (AnsiChar / AnsiString)
CreateFileW + PWideChar (WideChar / WideString / UnicodeString)

[roadrunner-S51]

Das ist schon richtig, aber manchmal nicht so einfach, wenn man 10 Jahre alten Code hat (schlecht kommentiert), der plötzlich in Delphi 2009 und mit anderer Pheriperie funktionieren soll. Da ist man dann irgedwie doch mal bereit, auch "Umwege" in Kauf zu nehmen.

[himitsu]

Wenn UsedComm als AnsiString/AnsiArray vorliegt, dann

Delphi-Quellcode:

CreateFileW(PWideChar(WideString(UsedComm)), ...

(AnsiString >> WideString > PWideChar > CreateFileW)

oder einfach nur

Delphi-Quellcode:

CreateFileA(@UsedComm[0], ...

(AnsiChar-Array > PAnsiChar > CreateFileA)

Durch die Umwandlung nach Unicode gewinnt man eh keine zusätzlichen Informationen.

[roadrunner-S51]

Danke! Das werde ich mir für das nächste Mal merken. Wie ich den Code der Programme hier kenne, wird das eher früher als später sein...