' schrieb:Was meinst du mit externem Thread? Ich hatte einmal eine "normale" Klassenarchitektur (abstrakte klasse und davon abgeleitete sind auch nichts anderes, nur anders organisiert) in denen ich die Datenaufnahme in einen Thread ausgelagert hatte und das funktionierte wunderbar.
Ein Thread der von einem Out Of Process Server gestarted wurde. Da das ein anderer Prozess ist als Deine LabVIEW Applikation, hat der auch keinerlei Idee von einer lvrt.dll und selbst wenn er die fände wäre das sinnlos, da Userevent Refnums nur in dem LabVIEW Context Sinn machen der sie auch erzeugt hat (und mit Context meine ich hier nicht nur den LabVIEW Prozess sondern die Application Referenz, wobei beispielswiese ein VI aus einem Project aufgestartet eine andere Applikation Referenz hat als ein anderes VI das global oder aus einem anderen Projekt heraus gestartet wurde).
Diese letzte Information ist allerdings zu Deiner Fehlermeldung irrelevant da Du in dem Fall von PostLVUserEvent einen error 1, manager Argument Error oder ähnlich zurückerhalten würdest, weil die Userevent Refnum ungültig ist. Aber soweit kommts bei Dir nicht mal, da die entsprechende Funktion die PostLVUserEvent aufruft in einem anderen Prozess aufgerufen zu werden scheint dann Deiner LabVIEW Applikation.
Ich tippe noch immer auf eine Callbackfunktion die Du an Deinen Treiber gibts und die dieser aus einem anderen Prozess oder was auch immer auszuführen versucht. Wahrscheinlich ist da sowas wie ActiveX Marshalling involviert und der Treiber erwartet dass Deine Callbackfunktion von einem anderen Prozess aus ausgeführt werden kann und selber das Marshalling der entsprechenden Daten in Deinen Zielprozess (hier LabVIEW) durchführt. Wenn dem so wäre hast Du eine "schöne" Aufgabe vor Dir.
Ersetzen der PostLVUserEvent() Funktion durch Windows Events wäre dann wohl eine der besseren Lösungen. Das könntest Du innerhalb des LabVIEW Prozess dann wieder durch einen eigenen Thread in PostLVUserEvents() umsetzen.
Rolf Kalbermatter