Zitat von himitsu:

Robert kann man ja leider nicht mehr fragen

Leider - seine freundliche und hilfsbereite Art war schon was besonderes.

Zitat von himitsu:

aber wie wäre es mit einer anderen Idee...
Was lastet denn deinen Hauptthread so aus und kann man das nicht auch in einen Thread auslagern?

Prinzipiell nicht falsch, der Gedanke. Aber das Ding ist schon ziemlich komplex und alle zeitkritischen Sachen sind in eigenen Threads (so 8 oder 9 mittlerweile). Das was da jetzt noch im Hauptthread passiert ist in erster Linie UI-Geschichte - und die in einen Thread legen ist nicht so sinnvoll.

Das Problem tritt ja auch nur manchmal auf - vor allem wenn auf dem Rechner viel los ist. Nachdem aber mit dem System Messdaten aufgezeichnet werden, sollte es einfach NIE passieren - und genau dafür ist das ganze ja auch in einem Thread. Das Konzept mit dem Thread für die USB-Kommunikation wird nur von dem Synchronize im DeviceController durchbrochen - da bringt dann das ganze Multithreading nix...

Zitat von himitsu:

[add]
Tja, der TJvHidDeviceController ist halt darauf ausgelegt, daß er im Hauptthread läuft, da er teilweise mit Messages arbeitet.

Im Anhang mit einigen kleinen Änderungen:
- wird TJvHidDeviceController, bzw. TJvHidDeviceReadThread in einem Thread erstellt, dann wird ohne Synchronize gearbeitet.

Danke, das hab ich mir auch schon geschnitzt. Ich war mir nur nicht wirklich sicher, ob das Synchronize noch einen anderen Zweck hat, als das Eventhandling sicher zu machen. (Was bei mir egal ist, da meine Event-Routinen alle Thread-safe sind).

Danke für die Mühe,

Luggi

Da diese Komponente ja standardmäßig (billig) auf eine Form geklatscht wird
und die Events dort angehangen sind, ging er eben davon aus, daß diese Events (standardmäig) nicht threadsicher sind.