(24.06.2019 17:07 )Natalie1984 schrieb: ich weiß jetzt nicht, welche von den beiden Möglichkeiten die beste ist.
Wenn du mich fragst, ist die Lösung mit dem Benutzer-Event die elegantere Lösung. Die bedarf nämlich nicht des Pollens nur für den Zweck, festzustellen, ob der Trigger da war.
Einfacher ist natürlich die Lösung mit der FGV.
Zitat:Wieso kann der Ereignis Callback, nicht einfach einen True Wert ausgeben, sobald sie getriggert wurde?
Der Callback, eigentlich das SubVI, das beim Callback aufgerufen wird, hat im Normalfall keinen Ausgang. Das Callback-VI sollte nämlich als asynchrones SubVI ausgeführt werden. Und sobald es asynchron ist, kann es in keinem Ablauf eingebunden sein, in dem dann Ausgänge sinnvoll sind. (Außerdem kann das Callback-SubVI nicht ausgeführt werden in Sinne "in einen Datenfluss einbinden": Solange es ausgeführt würde, würde der Trigger nicht funktionieren - theoretisch).
Zitat:Warum muss ich da noch so einen Aufwand umprogrammieren?
Um den asynchronen Aufruf in dein synchrones Programm einzubinden (Datenflusssteuerung!).
Zitat:Ich habe mir zwar die FGV (Functions Globale Variablen) schreiben angesehen, doch das ist aber nicht wonach ich suche oder?
Doch. Das ist das, was ich gemeint habe: Case in While-Schleife mit Variant-Dateneingang und Enumerator.
Zitat:Wenn ich die Ereignisstruktur in die SubVI reinlege, dann muss ich ja wieder die DLL aufrufen !?
Ja und?
Zitat:Da muss doch was einfaches geben, sobald das Event getriggert wird!
Keiner hat gesagt, dass .NET-Callbacks, also Delegates, einfach zu programmieren sind. Nicht das Event wird getriggert, sondern das SubVI wird getriggert durch den Event, d.h. der Event triggert.
Die Sache mit der FGV ist doch ganz einfach: .NET-DLL macht einen Callback. Im getriggerten SubVI werden die Daten aus der DLL in eine FGV gelesen. Diese FGV wird im MainVI und überall sonst verwendet.
