AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Thema durchsuchen
Ansicht
Themen-Optionen

Handle auf ComPort

Ein Thema von onzelonz · begonnen am 14. Apr 2010 · letzter Beitrag vom 14. Apr 2010
Antwort Antwort
onzelonz

Registriert seit: 14. Apr 2010
3 Beiträge
 
#1

Handle auf ComPort

  Alt 14. Apr 2010, 09:03
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
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.157 Beiträge
 
Delphi 12 Athens
 
#2

Re: Handle auf ComPort

  Alt 14. Apr 2010, 10:26
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;
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
R2009

Registriert seit: 9. Mär 2009
Ort: Heidelberg
440 Beiträge
 
Delphi 2007 Professional
 
#3

Re: Handle auf ComPort

  Alt 14. Apr 2010, 10:35
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
Rainer Unger
Mein Profil:
Studium Allgemeine Elektrotechnik TH Darmstadt
Entwicklung von Tools für die Rundsteuer und Zählertechnik.
uP's Atmel Prozessoren (ATmega16,32,88...) in C und Assembler.
  Mit Zitat antworten Zitat
onzelonz

Registriert seit: 14. Apr 2010
3 Beiträge
 
#4

Re: Handle auf ComPort

  Alt 14. Apr 2010, 10:57
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
  Mit Zitat antworten Zitat
Benutzerbild von himitsu
himitsu
Online

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
43.157 Beiträge
 
Delphi 12 Athens
 
#5

Re: Handle auf ComPort

  Alt 14. Apr 2010, 11:46
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.
Garbage Collector ... Delphianer erzeugen keinen Müll, also brauchen sie auch keinen Müllsucher.
my Delphi wish list : BugReports/FeatureRequests
  Mit Zitat antworten Zitat
onzelonz

Registriert seit: 14. Apr 2010
3 Beiträge
 
#6

Re: Handle auf ComPort

  Alt 14. Apr 2010, 17:31
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...
  Mit Zitat antworten Zitat
Benutzerbild von Chemiker
Chemiker

Registriert seit: 14. Aug 2005
1.858 Beiträge
 
Delphi 11 Alexandria
 
#7

Re: Handle auf ComPort

  Alt 14. Apr 2010, 19:19
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
wer gesund ist hat 1000 wünsche wer krank ist nur einen.
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:14 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz