Anwendung blockiert wenn das Fenster gezogen wird

[Poolspieler]

Hallo,
ich habe ein Programm geschrieben, welches nach einem Buttonclick mit einem USB-Gerät kommuniziert und die Daten auf dem Bildschirm ausgiebt. Das funktioniert so weit auch gut (die Kommunikation mit dem USB-Gerät ist aber äußerst Zeitkritisch!)

Problem:
Wenn der User das Hauptfenster mit der Maus verschiebt, dann scheint meine Anwendung für die Dauer des gedrückten Mausknopfs zu "stehen". Durch diese Blockierung (ich schätze, der Algorithmus steht bei hauptfenster.update) wird die Kommunikation mit dem USB-Gerät unterbrochen :-(

Hat jemand eine Idee dieses Problem zu lösen:
- ohne einen zweiten Thread zu nutzen?
- ohnen einfach den Rahmen des Hauptfensters zu verstecken?

Vielen Dank schon mal

Poolspieler

[Flocke]

Ich glaube, du wirst wohl nicht umhin kommen, einen eigenen Thread für die Kommunikation mit dem USB-Gerät zu nehmen.

[Robert Marquardt]

Genau, aber selbst dann kann Windows dir ans Bein pissen. Fenster mit der Maus ziehen ist in Windows grottenschlecht implementiert und kann leicht 100% CPU-Last erzeugen.
BTW was machst du denn genau mit USB?

[Poolspieler]

Das trifft mich hart, denn mein Projekt steht im Prinzip schon und es bedeutet wahrscheinlich einen hohen Aufwand, es in Threads umzuschreiben :-(

Das USB-Gerät ist ein von mir geschriebener µC der über einen FTDI-Chip mit dem PC kommuniziert.

Die komplette Komunikation erledigt eine einzige Klasse, die erstmal von dem Formular gekapselt ist - und das ist ja auch gut so ... ;-)
Lediglich im Konstruktor dieser Klasse wird z.B. ein Zeiger auf einen Chart mitgegeben.
Wird die Startmethode (meineKlasse.start() ) der Klasse aufgerufen, so werden Daten vom USB-Gerät empfangen und direkt auf dem Chart ausgegeben (inklusive eines "Update-Aufrufs"...)
Problem beim ziehen des Fensters: Das USB-Gerät schickt weiter Daten, die in den Puffer des FTDI-Treibers geschrieben werden. Umso länger die Anwendung blockiert ist, umso mehr Daten werden gepuffert, was natürlich zum Problem werden kann (nicht muss...)

Wenn nun diese Startmethode einen eigenen Thread starten würde, wie müßte ich dann die Echtzeitanzeige realisieren - ist das Stichwort TThread.synchronisize? Oder bin ich dann genauso weit? Sorry, aber mit Threads habe ich noch nicht viel programmiert...

Ich habe auch schon ein wenig gegoogelt. Es ist wohl erstmal gar nicht so einfach, von einem zweiten Thread direkt z.B. den Text eines Labels zu ändern.
--> Dort kamen dann Vorschläge wie: Starte vom Thread einen zweiten Thread, der dann die Daten im Formular ausgiebt --> das klingt irgendwie kompliziert, wenn man mich fragt...

Hat jemand bessere Ideen?

Gruß

Poolspieler

[Robert Marquardt]

Ist es ein HID-Geraet?

[Poolspieler]

Nicht ganz:

Mit diesem Chip kannst Du einen USB-Serial-Wandler bauen.
Wenn man den Serial-Treiber verwendet, dann taucht das Gerät im Gerätemanager als COM-Port auf und kann natürlich auch als solcher verwendet werden.
Ich habe den anderen Treiber verwendet, damit ist man noch etwas flexibler und hat ein paar mehr Features. Man kann z.B. jedem Gerät einen eindeutigen Namen geben (der wird in einem EEPROM gespeichert)
Hier der Link zum Chip: Webseiten-Titel

Im Prizip kann man sich das USB-Gerät aber als COM-Port mit ASCII-Interface vorstellen.
Die erste Version davon konnte man auch mit dem Hyperterminal bedienen (bevor ich auf den anderen Treiber umgestiegen bin...)

Gruß

Poolspieler

[Robert Marquardt]

Bei USB musst du mir nichts erklaeren.
Ein USB nach RS232-Adapter also. Warum sprichst du ihn nicht als COM Port an?
Async Pro z. B. duerfte sowieso mit Threads arbeiten.