COM Ports im System auslesen

[TurboMagic]

Hallo,

eine solche Komponente brauchst du dafür gar nicht.
Platziere eine TApplicationEvents Komponente (gibt's hoffentlich in D6 schon)
auf deiner Form und schaue dir mal die Events dieser an. Die sollte ein vergleichbares
bieten wie Rollo62 es benutzt hat.

Dort dann mal den Inhalt seiner WinProc Methode einfügen.

Grüße
TurboMagic

[Rollo62]

Das ist eine eigene Klasse, in der ich das gekapselt habe.
Ich hatte ja geschrieben das dort auch noch mehr drumrum zur Absicherung ist.

[himitsu]

Vermutlich musst du vorher dein Programm noch registieren, damit was ankommt.
https://docs.microsoft.com/en-us/win...enotificationa


und deine Codes bitte in [DELPHI]...[/DELPHI] oder [CODE]...[/CODE]

[1967Schorsch]

Ich habs dann irgendwie geschafft ein ApplicationEvents per Komponente einzufügen (Anfängerglück ).
In den Events sehe ich jetzt nicht was so ähnlich heißt wie seine TSerialManager.WinProc Prozedur.

[himitsu]

Application.OnMessage (Unit Forms) oder besser TApplicationEvents.OnMessage, weil es das mehrfach geben kann und man sich nicht selbst überschreibt.

Dort kommt alles vorbei, was via PostMessage und PostThreadMessage im Hauptthread des Programms eintrudelt,
und durch Application.Run bzw. Application.ProcessMessages/HandleMessage durchrauscht. (die Hauptbearbeitungsstellen der MessageQueue für unsere VCL)

Probleme gibt es nur, wenn jemand/etwas PeekMessage/GetMessage manuell aufruft und es nicht über Application.ProcessMessages oder .HandleMessage behandeln lässt, welche das OnMessage aufrufen.
z.B. in einigen Implementationen von Delay, als Nichthängenbleibender Ersatz des Sleep oder während ein Windows-Dialog ala MessageBox angezeigt wird.

Diese Messages dürften via PostMessage als Broadcast im System verteilt werden
und standardmäßig nur an TopLevel-Fenster, wie z.B. die Hauptform oder das unsichtbare ControlWindow in Forms.Application.

Wie gesagt, SendMessage kommt in dem Event blöder Weise nicht vorbei, dafür müsste man sich einen GetMessage-Hook basteln, falls es so ankommt.
https://docs.microsoft.com/en-us/win...sg/about-hooks


Es kann aber sein, dass diese Message hier nur an jene Fenster gesendet wird, welche sich vorher registriert haben.
https://docs.microsoft.com/en-us/win...enotificationa

Das Problem mit den an falscher Stelle behandelten/abgefangenen Messages, genauso wie für das übersehene SendMessage,
kann man sich da nun das WndProc seiner Form überschreiben oder die Message direkt anhängen,

Delphi-Quellcode:

procedure WndProc(var Message: TMessage); override;
bzw.
procedure WMDeviceChangeOderSo(var Message: TMessage); message WM_DEVICECHANGE;  // hier geht statt TMessage auch ein passender Typ, siehe TWMSize in Forms.pas

oder man empfängt sowas in einem eigenen Thread mit einer unabhängigen "unsichtbaren" MessageOnly-Form (ähnlich der in Application).

[1967Schorsch]

Hallo,
ich denke ich habe verstanden was du mir sagen willst.

Schade das es mit der Version (Delphi 6, ApplicationEvents Komponente) wohl nicht geht oder nicht so einfach ist.

Sich eine GetMessage-Hook basteln hört sich interessant an, nur wenn man (ich) nicht weis was man da tut, ist es schier unmöglich.
Schade und das nur um mitzubekommen ob der ausgewählte COM Anschluss/ USB Adapter abgesteckt wurde. Die Kommunikation über den Port erledigt ein anderes Programm was erst danach aufgerufen wird.

DANKE !!!

[1967Schorsch]

Ich habe nochmal geschaut ..... mit meiner Software steuere ich per ShellExecute die AVRootloader Software an.
Nach Rescherge wurde diese durch Hagen in Delphi 5 geschrieben. Die Behandlung der COM Schnittstelle funkrioniert wie ich das auch hinbekommen möchte. Dann hat er sich sicher auch ein GetMessage-Hook gebastelt.

Hier Version 6 der AVRootloader Software aus dem Microcontroller Forum
https://www.mikrocontroller.net/topi...195903#1195903

[HolgerX]

Hmm..

Zitat von 1967Schorsch:

Schade das es mit der Version (Delphi 6, ApplicationEvents Komponente) wohl nicht geht oder nicht so einfach ist.

Sich eine GetMessage-Hook basteln hört sich interessant an, nur wenn man (ich) nicht weis was man da tut, ist es schier unmöglich.
Schade und das nur um mitzubekommen ob der ausgewählte COM Anschluss/ USB Adapter abgesteckt wurde. Die Kommunikation über den Port erledigt ein anderes Programm was erst danach aufgerufen wird.

Anbei mal ein einfaches Testtool..
Dieses Reagiert, wenn ich ein USB/COM Adapter einstecke, bzw. Abziehe und gibt mir den entsprechenden Port (COM3..).

Das WM_DEVICECHANGE für DBT_DEVTYP_PORT wird übrigens ohne Registrierung an jedes TopLevel (Hauptfenster) einer Applikation geschickt.

Wie Du siehst nur wenig Source-Code.

Erstellt mit D6 und getestet auf Windows 7.

[1967Schorsch]

Hallo Holger,
super klasse...... genau das habe ich gesucht.

Vielen Dank für die Hilfe