Ich hab nur keine Ahnung, wie ich das in einem Nebenthread laufen lassen soll.

Ich weiße dem Event DataArrival meines SendOCX-Objekts einfach eine Funktion zu. Die wird dann eben aufgerufen, sobald das Event eintritt.
Wie kann ich sowas denn in einem komplett seperaten Thread laufen lassen?

Hatte ich schonmal beschrieben: erzeuge ein Timer-Objekt und löse dieses mit einer Verzögerung von 50ms aus, sobald das Event ausgelöst wird. Innerhalb des Events legst Du die empfangenen Werte in eine globale Variable und lagerst die gesamte Bearbeitung in den Timer aus. Den Timer deaktivierst Du gleich beim ersten Aufrufen wieder, sodass es nur einmal durchläuft. Das ist die simpelste Form, eine Entkopplung durchzuführen.

Aber es wird doch nicht mal das DataArrival-Event ausgelöst, wenn der Hauptthread ausgelastet ist.
Also wird weder der Timer gestartet, noch die Werte in seperate Variablen geschrieben.
Wenn dann müsste ich alles andere in seperate Threads auslagern, damit der Hauptthread garnichts zu tun hat.

Jetzt reden wir wohl aneinander vorbei..?

Also nochmal zusammengefasst: eine Rückkopplung und dadurch "Stockern" von CES kann nur dann stattfinden, wenn zum Zeitpunkt der Kommunikation eine Verzögerung auf der anderen Seite eintritt. Wenn also zum Zeitpunkt des Auslösens des DataArrival-Events Deine App ausgelastet ist, kann sich das auf CES auswirken. Dein Event wird aber nur dann ausgelöst, wenn Du unmittelbar davor eine Anfrage an CES gesendet hast - hier kannst Du also selber reagieren und sicherstellen, dass Du parallel zu dieser Anfrage nicht andere, prozesslastige Aufgaben durchführst.

Und nun zurück zu Deiner letzten Aussage: bedeutet dass, dass CES stockert, ohne dass Du über die IPC mit CES sprichst?

Es ist leider kein Stocken, das ich momentan zu 100% nachbilden kann, deshalb ist ja die Fehlersuche so schwer.


Mag sein, dass wir aneinander vorbeireden.

Ich hab dich so verstanden, dass das DataArrival-Event im Hauptthread abgearbeitet wird. Ist mein Hauptthread ausgelastet, wird auch das Event nicht verarbeitet.
Die restliche App lahmzulegen bis die Antwort von CES eintrifft finde ich nicht wirklich gut. Da ist es mir lieber, wenn ich alles andere in einen eigenen Thread bzw. in mehrere eigene Threads packe.

Zitat:Die restliche App lahmzulegen bis die Antwort von CES eintrifft finde ich nicht wirklich gut

Also man kann die Sache auch gravierend auslegen, obwohl es so nicht ist CES antwortet unmittelbar nach absenden der Anfrage - wir reden hier von Millisekunden. Wie Du deine App-Codestruktur aufbaust, kann ich nicht feststellen, aber ein Programm wird so oder so von oben nach unten abgearbeitet. Wenn Du zur Zeit sowieso nicht mit Threads arbeitest, hast Du nur einen Prozess, welcher abgearbeitet wird. Der Fehler hier wäre, wenn Du nun eine Funktion oder einen Prozess von oben nach unten mit prozesslastigen Aktivitäten so gestaltest, dass irgendwo mittendrinnen die IPC-Schnittstelle abgefragt wird. Das würde bedeuten, dass nach Erhalt der CES-Werte erstmal zig Dinge in Deinem Prozess abgearbeitet werden müssen, bevor CES vom Thread wieder gelöst wird - und genau das verursacht einen Hänger. Das ist der Nachteil an einer synchronen Kommunkationsbasis, wenn sie nicht sauber genutzt wird. Eine Asynchrone Kommunikation kommt hier gezielt nicht zum Einsatz. Wie Du nun die synchrone Verarbeitung "entkoppelst" (also die liefernde Applikation gleich wieder "lös lässt", sobald die Werte übertragen wurden) habe ich Dir ja bereits mit dem Timer sehr simpel als Beispiel genannt.

Hin oder her: die IPC-Schnittstelle von CES4 hat eine jahrelange Entwicklungsreife hinter sich und aktuell werden ein dutzend werkseitiger Apps und ein weiteres Dutzend Business-Apps über diese Schnittstelle fehlerfrei betrieben. Ich schließe nie aus, dass irgendwo ein Fehler schlummert, aber bei der IPC-Schnittstelle bin ich mir zu 99,99% sicher, dass diese einwandfrei läuft.

Aber da ich das entwickeln individueller Anwender-Apps unterstützen möchte, versuche ich Dir hier zu helfen und die Ursache zu finden. Ich würde vorschlagen, Du zeigst mir den betroffenen, endgültigen Sourcecode.

---

PS: Threads werden in keiner CES-App genutzt. Das ist immer ein einzelner Thread. Was auch im Normalfall völlig reicht. Wenn man es aber genau nimmt, ist das auslösen eines Timer-Objektes auch schon ein eigenständiger Thread

Ich arbeite natürlich mit mehreren Threads, aber ich sehe einfach den Fall, das CES aus welchem Grund auch immer irgendwelche Hänger hat, was unbestritten auftreten kann.
Ich werds schon irgendwie hinkriegen

Gab es diese Hänger schon, bevor Du deine App geschrieben hast? Vielleicht hat es ja nichts mit Deiner App zu tun - sondern ein völlig anderer Grund?!

Das mag alles sein Gueven, ich kann momentan echt nichts 100%iges sagen.
Vermute aber nach deinen Aussagen, dass es an meiner App liegt.

Na das lässt sich ja einfach nachvollziehen: entferne Deine App aus dem App-Verzeichnis und tuckere ein paar Tage ohne die App herum - wenn die Hänger eintreten, ist der Fehler woanders zu suchen :-) wenn nicht, dann ist es erstmal auf Deine App bzw. die IPC-Schnittstelle in Kombination mit Deiner App zurückzuführen. Dann wissen wir zumindest mal, dass wir an der richtigen Stelle suchen!

Bei Letzterem würde ich dann auch noch differenzieren zwischen einer App, die nur auf dem CarPC werkelt und einer, die auch Richtiung Fremdplattform kommuniziert (z.B. Android).