mehrere forms überwachen

[blackfin]

Ob die Kommunikation nun in einem eigenen Thread oder auch im Mainthread der Applikation laufen kann, kommt ja hauptsächlich drauf an, wie "blockierend" die Kommunikation an sich ist.
Aber die Kommunikation generell komplett von der GUI zu trennen, ist schon einmal eine sehr gute Idee
Dann kannst du nacher auch die GUI komplett austauschen, ohne dass du damit die Kommunikation beeinflusst.
Also den kommunkations-Code in eigene Klassen / Units kapseln oder auch in ein Datenmodul oder sowas in der Art, aber nicht in den Code der Form(s), denn das würdest du bald bereuen
Was meinst du eigentlich mit "wenn ein Gerät abstirbt"? Wenn die Kommunikation zusammenbricht? Das sollte generell mit der GUI gar nichts zu tun haben, sondern das soll die Kommunkations-Klasse abfangen können und eventuell dann eine Nachricht an die GUI senden können (oder die GUI pollt den Status, je nachdem was du genau vorhast), aber nicht so, dass dann die GUI abraucht

Ich habe so etwas auch schon einmal gemacht, ein Programm, dass drei Geräte überwacht.
Dazu habe ich mir erstmal die Kommunkations-Klasse für die Datenstrukturen und Befehle des Gerätetyps an sich geschrieben, im Programm dann selbst ein Datenmodul, das Instanzen dieser Geräte erzeugt / registriert und die Kommunkation der Geräte unter sich koordiniert. Die GUI-Forms an sich empfangen und senden dann nur noch Events vom Datenmodul, sind also reine Anzeigen und Empfänger für Tastatur-Mausangaben, die aber an die Logik-Schicht übergeben werden, die dann wiederum die Events feuert usw.

Somit habe ich dann drei Teile, die einzeln wartbar sind:
1) Kommunkations-Klasse für das Geräte-Protokoll (Klasse)
2) Logik-Schicht, die die Geräte-Instanzen koordiniert (Datenmodul)
3) GUI, die User-Eingaben annimmt und Meldungen anzeigt. (Forms)

Ausblick / Erweiterungen:
Was sich bei einer Geräte-Verwaltung nach meiner Erfahrung zudem noch anbietet, ist eine Art Scripting-API für das Programm und dessen Events, vor Allem dann, wenn es sich bei der Software oder sogar dem Gerät selbst um einen Prototypen handelt, bei dem noch nicht alle Gegebenheiten klar sind.
Dann macht es Sinn, die Events und Funktionen von Kommunkations- Logik- und GUI-Schicht, durch eine API-Schnittstelle nach Aussen hin zugänglich zu machen und die Verbindungen über Scripting zu realisieren. Das hat den Vorteil, dass der Kunde teilweise selbst festlegen kann, was angezeigt / gemacht werden soll, wenn ein bestimmtes Ereignis eingetreten ist. Gute Erfahrungen habe ich hier mit Lua gemacht, für Delphi bietet sich aber wahrscheinlich PascalScript mehr an.

[snook]

mit absterben meine ich so ziemlich alles was ein programm zum hängen bringen kann. ich bin für die gerätetreiber nicht verantwortlich, den schreiben die user je nach bedarf. da können dann so schöne sachen wie endlosschleifen mal ganz schnell passieren, oder es gibt AV's weil beim lesen der config was nicht hinhaut und der klassiker ist natürlich ein loses kabel, sodass die kommunikation zusammenbricht. das würde ich halt alles gerne vom gerätecontroller heraus abfangen können (dem ist es ja egal warum ein gerät nicht mehr reagiert).
danke schonmal für die struktur, die klingt ja ganz vernünftig