Handle auf ComPort

[onzelonz]

hallo!

ich habe eine funktion geschrieben, die (in einem thread) prüft, welche
comports (ob ein comport...) am system vorhanden sind:

Delphi-Quellcode:

function TConThread.getPrt(Port: String): Boolean;
var
  ComFile       :     THandle;
  DeviceName    :     array [0..10] of Char;

begin

  StrPCopy(DeviceName, Port);

  try

    ComFile := CreateFile(DeviceName, GENERIC_READ or GENERIC_WRITE, 0, nil,
      OPEN_EXISTING,
      FILE_ATTRIBUTE_NORMAL, 0);

    Result := ComFile <> INVALID_HANDLE_VALUE;

    if NOT (ComFile = INVALID_HANDLE_VALUE) then
      begin
        CloseHandle(ComFile);
      end;

  except
    MessageDlg(IntToStr(GetLastError)+':hnd', mtError, [mbOK], 0);
  end;
end;

die portnamen werden im format '\\.\COMxx' übergeben.

wenn ich nun ein usb-gerät anstecke, dass intern als com port gehandelt wird,
so habe ich das problem, dasss mir dieses gerät einmal erkannt wird, einmal nicht
(ich also einen handle darauf bekomme).
ich kann es manchmal 10x an und abstecken, und es wird immer sauber erkannt,
manchmal nur einmal usw...

meine frage ist nun:
an was kann das liegen?
das gerät wird im gerätemanager von windows (=vista) immer korrekt angezeigt.
hat jemand eine idee? bin für jeden hinweis dankbar

gruss
peter

[himitsu]

Zitat von onzelonz:

[/delphi]except
MessageDlg(IntToStr(GetLastError)+':hnd', mtError, [mbOK], 0);
end;[/delphi]

Entweder es ist ein API-Fehler, welcher in GetLastError zurückgeliefert wird
oder es ist eine Exception, deren Information im Exception-Objekt drinsteht.


Exceptions sollte man eigentlich auch nicht einfach so abfangen und unbehandelt in nichtssagende Meldungen umwandeln:

Delphi-Quellcode:

function TConThread.getPrt(Port: String): Boolean;
var
  ComFile : THandle;

begin
  ComFile := CreateFile(PChar(Port), GENERIC_READ or GENERIC_WRITE, 
    0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
  Result := ComFile <> INVALID_HANDLE_VALUE;
  if Result then 
    CloseHandle(ComFile)
  else
    Raise Exception.Create(SysErrorMessage(GetLastError));
end;

aber wenn du unbedingt Exeptions unterdrücken willst, dann zeige wenigsten die "richtigen" Fehlermeldungen an:

Delphi-Quellcode:

function TConThread.getPrt(Port: String): Boolean;
var
  ComFile : THandle;

begin
  try
    ComFile := CreateFile(PChar(Port), GENERIC_READ or GENERIC_WRITE, 
      0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
    Result := ComFile <> INVALID_HANDLE_VALUE;
    if Result then 
      CloseHandle(ComFile)
    else
      MessageDlg(SysErrorMessage(GetLastError), mtError, [mbOK], 0); 
  except
    on e: Exception do
      MessageDlg(E.Message, mtError, [mbOK], 0); 
  end;
end;

Ohne Exceptionbehandlung und da die WinAPI nur selten mit Exceptions um sich wirft, sondern vorwigend GetLastError nutzt und da CloseHandle bei einem INVALID_HANDLE_VALUE nichts macht:
(falls man doch die Meldung haben will, dann Diese einfach auskommentieren)

Delphi-Quellcode:

function TConThread.getPrt(Port: String): Boolean;
var
  ComFile : THandle;

begin
  ComFile := CreateFile(PChar(Port), GENERIC_READ or GENERIC_WRITE, 
    0, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0);
  CloseHandle(ComFile);
  Result := ComFile <> INVALID_HANDLE_VALUE;
  //if not Result then 
  //  MessageDlg(SysErrorMessage(GetLastError), mtError, [mbOK], 0); 
end;

[R2009]

Hi,

ich will ja nicht meckern aber asynchpro kann das alles!
Dort gibts eine fertige Funktion dafür.

Ich weiss nicht warum man sich solche Mühe macht.

Grüsse
Rainer

[onzelonz]

hi

also erstmal danke für die schnellen antworten;

@rainer:
1. weil man asynchpro nicht kennt
2. weil mans kapieren will ?!?

@himitsu:
ich habe versucht, es nach deinen beispielen umzusetzen,
aber das problem ist immer noch das selbe:

ich bekomme keine exception zurrück.
demnach ist alles sauber gelaufen.
wenn ich debugge, dann bekomme ich zwar auf den statische port com1
ein sinnvolles handle, auf den des geräts (im gerätemanager als zb. com8 angezeigt)
bekomme ich aber keins - zumindest kein sinnvolles (nummerishc 4294967295, wie auch
bei angefragten ports, die nicht vorhanden sind, da ich port 1-64 abfrage mit einer schleife);

wenn cih allerdings das gerät an einen anderen usbport stecke, so ändert sich - natürlich - die comportnummer
und das gerät wird wieder "erkannt". nach mehrmaligen verbinden geht aber auch dort das spiel von vorne los.
ich kann den usbport nicht wechseln, da das gerät 1. via cradle verbunden ist und 2. das ja auch irgendwie "unzumutbar" wäre.

kann es sein, dass der comport (oder das handle), welcher auf das usb gerät zeigt, irgendwie nicht mehr freigegeben wird bzw belegt ist??

thanx nochmals
peter

[himitsu]

Zitat von onzelonz:

bekomme ich aber keins - zumindest kein sinnvolles (nummerishc 4294967295,

4294967295 = INVALID_HANDLE_VALUE

Heißt also der Zugriff auf diesen Post ist nicht erlaubt (ungenügend Zugriffs- oder Sharingsrechte)
oder der Port wurde wirklich (noch) nicht verbunden.

[onzelonz]

blöde frage:

kann es sein, dass - wenn ich an anderer stelle auch auf den port zugreife - dieser dann dort nicht mehr sauber freigegeben wird?
und in diesem zusammenhang (habs jetzt aber grad nicht vor mir): wenn ich aus - und wieder einstecke (am selben usbport), kann es sein, dass das
handle dann das selbe bleibt?

vergebt meine unwissenheit, is das 1. mal, dass ich sowas mach...

[Chemiker]

Hallo onzelonz,

USB<>COM-Port

Es kann durchaus sein das es an den USB-COM-Port Adapter liegt. Ich habe 3 gekauft, bis ich einen hatte der einwandfrei funktionierte. Dabei war einer dabei der ca. nach 3 Tage nicht mehr vernünftig die Daten übertragen hat.
Als hilfreich hat sich das Programm COM0COM herausgestellt, um sicherzustellen dass es nicht an meinem Programm lag.

Bis bald Chemiker