Seit vielen Jahren nutze ich schon CPort-Compo ohne Probleme.
Nun zickt Sie rum ... das Problem:
Mein Proggie liest aus einer INI-Datei die Vorgabe für den
COM-Port ala 'COM3'.
Mit "EnumComPorts(TStrings)" (in CPort) lese ich die Liste der verfügbaren Ports und prüfe ob es die Vorgabe gibt.
Falls JA, Comport setzen, öffnen, auf connected prüfen und ab die DatenLuzie ... Zum Schluss ComPort schließen und gut.
Wenn ich mich nicht irre, gibt es dieses Tool schon seit D6. Ob ich das schon mal mit 10.3 am Start hatte ... weiß nicht mehr.
"Vorgabe nicht in den
COM-Liste" lautet meine Fehlermeldung - ich bekomme aber COM3 bei Auflistung angezeigt ?!
Beides ist groß geschrieben, also müsste das mit '=' funzen.
Also mal mit CompareStr, CompareText, SameStr, SameText probiert: Immer ungleich (Ergebnis 1, größer).
Erst mit AnsiCompareStr gab es ein Match. Gut, OK, weiter im Programm.
Alles läuft so weit mit dem alten Source: Freude kommt auf, wenn da nicht gelegentlich (NCHT IMMER) diese
AV beim beenden des Proggies wäre.
Irgendwas geht irgendwo in die Uhr weil von ungültiger Adresse "gelesen" wird. HÄ ?
Das hatte ich schon mal als ich auf einen versehentlich schon freigegebenen Record schreiben wollte.
Wie gesagt, die
AV kommt nicht immer, sondern nur ca. 5-8 von 10x. Sehr kurios !
Das wars aber nicht ! 3 Tage hab ich nun gesucht und bin zu dem Schluss gekommen:
Es ist die procedure EnumComPorts(Ports: TStrings);
Ich hatte mich wieder dem Portvergleich gewidmet und festgestellt, dass das Ergebnis der Stringliste (HIER) in jedem Eintrag nicht 4, sondern 9 Zeichen enthält:
Die Portbezeichnung als 4 Buchstaben plus 5 Nullen dahinter.
Das stört bei der Ausgabe so nicht weiter, beim Vergleich aber eben schon.
Nimmt man die Nullen raus, funzt alles wieder wie gewünscht und auch keine
AV mehr.
Hier scheint es offensichtlich, das ComPort.Open den vermeintlich ungültigen Namen noch akzeptiert (Port wird anstandslos geöffnet), aber innerhalb ComPort.Close scheint sich da irgendwas an den zusätzlichen Nullen zu stören.
Ich habe bisher noch nicht herausgefunden was/wo das sein könnte ...
Und woher kmmen die Nullen ?
DataLen gibt mir hier immer "10" aus und soll lt. MS-Docs die Anzahl Zeichen in Data angeben.
Da steht auch nichts von 'include the terminating null character' - also 6 Zeichen zuviel.
M. E. n. ein Fehler seitens Windoof (hier 8.1).
Ich hab die procedure mal ein wenig abgeändert - nu lüpp dat:
Delphi-Quellcode:
procedure EnumComPorts(Ports: TStrings);
var
KeyHandle: HKEY;
ErrCode, Index: Integer;
ValueName, Data: array[0..256] of char; // string;
ValueLen, DataLen, ValueType : DWORD;
begin
if NOT Assigned(Ports) then exit;
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE,
'HARDWARE\DEVICEMAP\SERIALCOMM',
0,
KEY_READ,
KeyHandle) <> ERROR_SUCCESS) then exit;
try
Index := 0;
repeat
ValueLen := 256;
DataLen := 256;
ErrCode := RegEnumValue(KeyHandle,
Index,
@valuename, // PChar(ValueName),
ValueLen,
nil,
@ValueType,
PByte(@Data), // PByte(PChar(Data)),
@DataLen);
if ErrCode = ERROR_SUCCESS then
begin
Ports.Add(Data); // TmpPorts.Add(Data);
Inc(Index);
end;
until (ErrCode <> ERROR_SUCCESS) ;
finally
RegCloseKey(KeyHandle);
end;
end;