CPort Komponente - Fehler bei Port-Enumeration

[himitsu]

Anzahl der "Byte"

(4 + 1) * 2 = 10 für Unicode (2 Byte pro Char)


Das Name in Char, aber die Data in Byte.

Allerdings willst du doch bestimmt den Name speichern? (hab grad keinen COM-Port dran und weiß seh nicht was in Data steht)



Ach ja, weil sind keine Strings, sondern statische Arrays:

Delphi-Quellcode:

// PChar(@ValueName),

// PByte(PChar(@Data)),

Wovei die PChar-Casts unnötig sind, da ein Zeiger auf einen Char ein bereits PChar ist.

[dummzeuch]

Zitat von himitsu:

Ach ja, weil sind keine Strings, sondern statische Arrays:

Delphi-Quellcode:

// PChar(@ValueName),

// PByte(PChar(@Data)),

Wovei die PChar-Casts unnötig sind, da ein Zeiger auf einen Char ein bereits PChar ist.

@ArrayOfChar ist kein PChar, das gilt nur für @ArrayOfChar[Index]

Das gibt sogar einen Comile-Error, wenn Typed @ Operator eingeschaltet ist, sonst wird das nicht geprüft.

[himitsu]

OK, den "strengen" Compiler vergessen, dann eben mit PChar Cast, oder einfach [0] hinten dran.


Du darfst gern, @StatischesArrayOfChar[0] anstatt @StatischesArrayOfChar machen, aber es macht keinen Unterschied (vom Speichermanagement her ... OK, die Typprüfung mal außen vor).

@AnfangDesStatischenArray (wo der erste Char liegt) = @ErstesCharImArray[0]


Aber "immer" mit [0] ist nicht falsch und würde zumindestens für statisches Array und dynamisches Array im Quellcode den selben Code verwenden, und die Typprüfung ist auch froh.
(weniger Varianten = weniger potentielle Fehler)

[TERWI]

PChar muss sein - der Compiler meckert, weil für Data ein PByte von RegEnumValue gefordert.
Bei Valuename passt das mit @.

Das it den 10 byte für ein WChar könnte Sinn machen ....
Data einzeln "durchbuchstabiert" in der org. Version ergibt z. B.
C O M 3 0 0 0 0 0 0 (ein Ansi-String)

Um in Wchar zu wandeln müsste es doch so aussehen ?:
0 C 0 O 0 M 0 3 0 0 (mit Null als Stringende)