Herrausfinden der aktuell vorhandenen COM-Schnittstellen

bierber

Hab da mal ne Frage zur Seriellen Schnittstelle und zwar will ich wissen wie ich herausfinde welche COM-Schnittstellen aktuell verfügbar sind und diese irgendwie in ein Array anlegen.

bzw. für jede verfügbare COM-Schnittstelle ein RadioButton erzeugt.

Vielen Dank für die Hilfe

MfG Felix

bierber

Gleich noch ne Frage zum verständnis in den ganzen beispielen wird bei der initaliesierung folgender Befehl eingegebn, nur was bedeutet das im einzelnen?

hCom = CreateFile ("COM1", GENERIC_WRITE | GENERIC_READ, 0, NULL, 
   OPEN_EXISTING, 0, NULL);

Also merci mal
mfg Felx

Braunstein

Hallo,

Hier mal ein paar Links zum Lesen

CreateFile
About Communications Resources
Vielleicht hilfts ja.

junix

EnumPorts ist da wohl ne passende API Funktion (Siehe msdn.microsoft.com)

Auch deine zweite Frage, die eignetlich nichts mit dem im Titel angegebenen Thema zu tun hat, (merke bitte für die Zukunft: Pro Frage 1 Thread, 1 Thread Pro Frage) findest du die Antwort in der MSDN, wenn du mal die Funktion nachschlägst...

bierber

OK erst mal sorry wegen meinem Regel verstoß kommt nicht mehr vor

nun hab ich mir alle Infos von euch durchgelesen aber ich komme da net weiter vielleicht gibt es da ein paar Code Schnippsel die mir mehr sagen als seitenlanges BLABLA

junix

bierber schrieb:

die mir mehr sagen als seitenlanges BLABLA

Seitenlages Blabla?!? Das ist die Entwicklerdokumentation, die dir eben Fragen wie diese hier beantwortet:

was bedeutet das im einzelnen?

Die Frage kann man ja ned mit Codeschnippseln beantworten?

Was hast du denn an der Dokumentation zu EnumPorts nicht verstanden?

MFK

MSDN schrieb:

The EnumPorts function enumerates the ports that are available for printing on a specified server.

Drucken?

Ich durchsuche HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM, das funktioniert sehr gut unter 2000 und XP. Ein Moderator - ich glaube KlausB - hat mal davon abgeraten, aber auf Nachfrage leider nicht geantwortet. Daher diesen Vorschlag bitte mit Vorsicht genießen.

KlausB

Hallo

Habe ich vergessen auf das damalige Posting zu atworten

Das Problem liegt doch daran: nicht in allen Windosen liegt es an der Stelle

HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

Mfg
Klaus

MFK

KlausB schrieb:

Habe ich vergessen auf das damalige Posting zu atworten

Hallo KlausB,

es handelt sich um diesen Thread: http://www.c-plusplus.net/forum/viewtopic-var-t-is-91717

Hey, das ist fast genau ein Jahr her

Das Problem liegt doch daran: nicht in allen Windosen liegt es an der Stelle
HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

Wie gesagt, unter XP und 2000 klappt das bei mir ganz gut. Hast du da nähere Informationen?

KlausB

Hallo

bei alle Windosen die auf NT basieren stimmt es so
bei Win9X usw ist es nicht ganz so
(oder anderst herum - bin mir nicht mehr ganz sicher wie herum)

Mfg
Klaus

junix

MFK schrieb:

MSDN schrieb:

The EnumPorts function enumerates the ports that are available for printing on a specified server.

Drucken?

Ich empfehle damit rumzuspielen, bevor man sich ein Urteil bildet... Vielleicht seid ihr ja alle auch zu jung um zu wissen, das es früher auch COM-Port-Drucker gab? (o;

MFK

junix schrieb:

Ich empfehle damit rumzuspielen, bevor man sich ein Urteil bildet...

Ich habe EnumPorts mal in einem Projekt benutzt und war mit dem Ergebnis nicht zufrieden. Ich wusste nicht mehr, warum, darum habe ich rumgespielt

Ergebnis:
EnumPorts liefert nicht nur serielle Schnittstellen. Das wäre kein Problem, wenn man irgendwie erkennen könnte, welcher Port eine ist und welcher nicht. Dazu habe ich aber auf die Schnelle keine Möglichkeit gefunden.

Außerdem liefert EnumPorts Schnittstellen, die gar nicht vorhanden sind. Mein Rechner hier hat weder COM3 noch COM4, und schon gar nicht LPT1, LPT2 und LPT3.

Damit ist EnumPorts IMHO zu Auffinden serieller Schnittstellen komplett ungeeignet.

junix

MFK schrieb:

EnumPorts liefert nicht nur serielle Schnittstellen. Das wäre kein Problem, wenn man irgendwie erkennen könnte, welcher Port eine ist und welcher nicht. Dazu habe ich aber auf die Schnelle keine Möglichkeit gefunden.

ganz einfach: Da werden weitere Infos mitgeliefert in denen "COMx" steht... nach COM filtern wirkt wunder (o;

MFK schrieb:

Außerdem liefert EnumPorts Schnittstellen, die gar nicht vorhanden sind. Mein Rechner hier hat weder COM3 noch COM4, und schon gar nicht LPT1, LPT2 und LPT3.

Das ist nach meiner Erfahrung betriebssystemabhängig. Bei NT4 z.B. trifft das zu.

MFK schrieb:

Damit ist EnumPorts IMHO zu Auffinden serieller Schnittstellen komplett ungeeignet.

Naja einzige alternative wäre das versuchte Öffnen aller Schnittstellen. Nur wo hört man da am Besten auf?

bierber

OK BLABLA nehme ich zurück aber wenn man halt neu ist in der C++ Welt die englische sprache zwar versteht und auch einigermaßen kann hat man doch Probleme seitenlange Texte aus dem Englischen korrekt zu verstehen.

Was mich an dem Artikel zusätzölich gestört hat war das immer vin Printern gesprochen wurde was meines erachtens ja den LPT1 Port betrifft ich aber die Com Schnittstelle suche.Was ja vom Datenformat extrem unterschiedlich ist(parallel und seriel)

Also vielleicht schaffe ich es selber ansonsten würde es mich freuen wenn man mir noch ein paar hilfreiche Tipps geben kann (

das mit der Regisitry durchsuchen war schonmal net schlecht nur wie sieht das mit usb to Serial adaptern aus stehen die dann dauerhaft drin oder nur wenn sie angeschlossen sind?

Und wie durchsuche ich überhaupt die Registry?

Naja ich hoffe habe jetzt nicht soviel unmut gegen mich geschürt das ich vielleicht noch ein paar weiter dämliche Fragen stellen darf.

MfG Felix

MFK

junix schrieb:

ganz einfach: Da werden weitere Infos mitgeliefert in denen "COMx" steht... nach COM filtern wirkt wunder (o;

Ist irgendwo festgelegt, dass der Gerätename einer seriellen Schnittstelle mit COM anfangen muss?

junix schrieb:

MFK schrieb:

Außerdem liefert EnumPorts Schnittstellen, die gar nicht vorhanden sind. Mein Rechner hier hat weder COM3 noch COM4, und schon gar nicht LPT1, LPT2 und LPT3.

Das ist nach meiner Erfahrung betriebssystemabhängig. Bei NT4 z.B. trifft das zu.

Es kommt noch schlimmer. Ich habe gerade ein wenig mit den BT-Comports herumgespielt. EnumPorts meldet COM5 und COM6, die es nicht gibt. Den frisch eingerichteten COM7 meldet es nicht
OS: Windows XP Professional, SP 2

junix schrieb:

Naja einzige alternative wäre das versuchte Öffnen aller Schnittstellen. Nur wo hört man da am Besten auf?

Einer unserer Kunden hatte serielle Schnittstellen im dreistelligen Bereich. Hinzu kommt, dass ein Fehlschlagen des Öffnens nicht bedeutet, dass die Schnittstelle nicht da ist.

bierber

Ok sowie es aussieht sind da doch noch mehr Probleme mit dem EnumPorts.

KlausB schrieb:

Hallo

bei alle Windosen die auf NT basieren stimmt es so
bei Win9X usw ist es nicht ganz so
(oder anderst herum - bin mir nicht mehr ganz sicher wie herum)

Mfg
Klaus

Wenn ich das richtig verstehe gibt es bei der Registry nur 2 möglichkeiten

entweder 98, me oder 2000 und XP ist es nicht möglich das betriebssystem auszulesen und dann den entsprechenden Registryschlüssel zu durchforsten?

ist auf jedenfall effektiver als 200 Com Ports zu testen.

MfG Felix

MFK

bierber schrieb:

ist es nicht möglich das betriebssystem auszulesen

GetVersionEx

und dann den entsprechenden Registryschlüssel zu durchforsten?

RegOpenKeyEx, RegEnumValue usw. Der BCB hat aber bestimmt eine Klasse dafür.

Braunstein

TRegistry

Nighthero

Ich mache dies immer damit:

//---------------------------------------------------------------------------
void TfrmOptions::LoadCommPortsList()
{
   COMMCONFIG CommConfig;
   AnsiString saTemp;
   DWORD dwSize = sizeof(COMMCONFIG);

   CommConfig.dwSize = sizeof(COMMCONFIG);

   for(int iPort = 1; iPort <= MAX_COMM_PORTS; ++iPort)
   {
      saTemp.sprintf("COM%1u", iPort);

      if(GetDefaultCommConfig(saTemp.c_str(), &CommConfig, &dwSize))
      {
         saTemp.sprintf("COM%1u (%s)", iPort, GetCommProviderSubTypeText(CommConfig.dwProviderSubType).c_str());
         cbxComPort_Imes->Items->Add(saTemp);
      }
      else
      {
         saTemp.sprintf("COM%1u (n/a)", iPort);
         cbxComPort_Imes->Items->Add(saTemp);
      }
   }
}

//---------------------------------------------------------------------------
AnsiString __fastcall TfrmOptions::GetCommProviderSubTypeText(DWORD dwProviderSubType)
{
   switch(dwProviderSubType)
   {
      case PST_FAX:
         return AnsiString("FAX");
      case PST_LAT:
         return AnsiString("LAT");
      case PST_MODEM:
         return AnsiString("Modem");
      case PST_NETWORK_BRIDGE:
         return AnsiString("Network bridge");
      case PST_PARALLELPORT:
         return AnsiString("Parallel");
      case PST_RS232:
         return AnsiString("RS232");
      case PST_RS422:
         return AnsiString("RS422");
      case PST_RS423:
         return AnsiString("RS423");
      case PST_RS449:
         return AnsiString("RS449");
      case PST_SCANNER:
         return AnsiString("Scanner");
      case PST_TCPIP_TELNET:
         return AnsiString("Telnet®");
      case PST_X25:
         return AnsiString("X.25");
      case PST_UNSPECIFIED:
      default:
         return AnsiString("?");
   }
}

Gruß Nighthero

junix

MFK schrieb:

junix schrieb:

ganz einfach: Da werden weitere Infos mitgeliefert in denen "COMx" steht... nach COM filtern wirkt wunder (o;

Ist irgendwo festgelegt, dass der Gerätename einer seriellen Schnittstelle mit COM anfangen muss?

Nicht das ich wüsste. Ging bis dato aber immer davon aus...

MFK schrieb:

junix schrieb:

MFK schrieb:

Außerdem liefert EnumPorts Schnittstellen, die gar nicht vorhanden sind. Mein Rechner hier hat weder COM3 noch COM4, und schon gar nicht LPT1, LPT2 und LPT3.

Das ist nach meiner Erfahrung betriebssystemabhängig. Bei NT4 z.B. trifft das zu.

Es kommt noch schlimmer. Ich habe gerade ein wenig mit den BT-Comports herumgespielt. EnumPorts meldet COM5 und COM6, die es nicht gibt. Den frisch eingerichteten COM7 meldet es nicht
OS: Windows XP Professional, SP 2

Das ist schlecht. Wusste ich bis jetzt auch nicht so. Überrascht mich ehrlich gesagt etwas...

MFK schrieb:

junix schrieb:

Naja einzige alternative wäre das versuchte Öffnen aller Schnittstellen. Nur wo hört man da am Besten auf?

Einer unserer Kunden hatte serielle Schnittstellen im dreistelligen Bereich. Hinzu kommt, dass ein Fehlschlagen des Öffnens nicht bedeutet, dass die Schnittstelle nicht da ist.

Korrekt. Aber zumindest bedeutet es, dass die Schnittstelle nicht verfügbar ist, da sie belegt wird. Und das reicht ja eigentlich schon. Denn es macht ja keinen Sinn, dem Benutzer die Möglichkeit zu geben, Schnittstellen zu kopnfigurieren, die nicht verfügbar sind?

Nightheros Ansatz hat 2 Nasen:
a) er geht ebenfalls davon aus, dass die Schnittstellen mit COM anfangen
b) Woher krieg ich MAX_COMM_PORTS?

MFK

junix schrieb:

Nicht das ich wüsste. Ging bis dato aber immer davon aus...

Ich eigentlich auch...

junix schrieb:

Überrascht mich ehrlich gesagt etwas...

Mich wundert gerade bei den Funktionen, die mit seriellen Schnittstellen zu tun haben, gar nichts mehr. Ich habe z.B. auch feststellen müssen, dass auf einigen Maschinen BuildCommDCB bei COM-Ports über 9 nicht mehr funtionierte

MFK schrieb:

Aber zumindest bedeutet es, dass die Schnittstelle nicht verfügbar ist, da sie belegt wird. Und das reicht ja eigentlich schon. Denn es macht ja keinen Sinn, dem Benutzer die Möglichkeit zu geben, Schnittstellen zu kopnfigurieren, die nicht verfügbar sind?

In dem konkreten Projekt war es ein Problem. Ich brauchte für einen Konfigurationsdialog die tatsächlich vorhandenen Schnittstellen, auch wenn die gerade durch irgendeine andere Anwendung belegt war. Denn so was ist ja nicht zwangsläufig von Dauer.

Nightheros Ansatz hat 2 Nasen:
a) er geht ebenfalls davon aus, dass die Schnittstellen mit COM anfangen
b) Woher krieg ich MAX_COMM_PORTS?

Ich hab das gerade mal getestet: GetDefaultCommConfig liefert mir für alles, was über "COM1" hinausgeht, FALSE. GetLastError ist 87, Invalid Parameter.