Hallo Zusammen, hallo Holger,
erstmal Vielen Dank für den Workshop. Ich habe mir die Doku des AF-Templates öfters durchgelesen, doch erst mit deiner praktischen Übung beginne ich nun ganz langsam dahinter zu steigen.
Zur ersten didaktischen Lücke habe ich noch weitere Fragen:
Im 'Preview Stack Msg.lvclass: Do.vi' soll der Stack an den Aufrufer zurück geschickt werden. Hierfür übergibt der Aufrufer seinen Self Enqueuer an die Methode 'Preview Stack Msg.lvclass: Send Preview Stack.vi'. Mir gefällt die Idee eine Referenz auf den Self Enqueuer des Nachrichtenaufrufers zu verwenden. Soweit ich das verstehe, wird es dadurch deutlich flexibler, da ansonsten nur der Aufrufer des Akteurs zu Verfügung stände, und das muss nicht der Sender der Nachricht sein.
Du schreibst, man könnte im einfachsten Fall aber auch die AF Funktion 'Read Caller Enqueuer' verwenden, um die Nachricht einfach immer an den Aufufer (des Akteurs, wenn ich richtig liege) zu senden. Wenn ich diese Funktion im Do.vi der Message platziere erhalte ich von LabView folgende Fehlermeldung
Zitat:This VI cannot access the referenced item because of class access scope. Items in protected scope can be accessed only from the following locations:
1) from inside the owning LabVIEW class
2) from inside LabVIEW classes inheriting from the owning LabVIEW class.
In der Doku des AF liest es sich so, als hätte jeder Akteur seine Queue, die des Aufrufers und die seiner "Kindakteure" im Zugriff. Hier befinden wir uns allerdings in einer seiner Nachrichten, die ja keine Kindakteure des Akteurs sind. Andererseits gibt es einen 'Actor in' - warum darf ich darauf nicht zugreifen?
Später im Workshop wird der Testaufruf vom Calculator-Akteur durch den eigentlichen Aufruf der UPNCalculatorGUI ersetzt. Ich vermute an dieser Stelle bin ich auf die zweite didaktische Lücke gestoßen? In Übung 7 soll ein "unerwarteter Zustand" gezeigt werden, wenn die beiden Akteure den gleichen Rechner verwenden. Ich vermute, was gemeint ist, ist dass die Testberechnung zu einer Veränderung des Stacks führt, von der die GUI so erstmal nichts mitbekommen hat... Aber bevor ich mir das ansehen kann schmiert mir LabView ab. Das Problem: Wir haben im Do-Teil der Nachricht das Send Preview Stack VI getauscht. Nun wird der Stack zurück an die UPNCGUI geschickt und nicht mehr an den Calculator. Löse ich nun die Testberechnung aus landet der Self Enqueuer von 'Calculator.lvclass' in der falschen Klasse 'UPNCalculatorGUI.lvclass', oder so ähnlich...?
Vorausgesetzt, man möchte den gleichen Actor für verschiedene GUIs gleichzeitig nutzen. Wie erreicht man also, dass der Empfänger einer Nachricht, seine Daten an einen beliebigen Aufrufer zurückgibt? *kopfkratz*
- Ich könnte im UPNC für jeden Aufrufer eine eigene Nachricht anlegen, welche dann genau weiß, an wen sie die Daten zurück zu schicken hat. Das scheint mir aber nicht sehr flexibel zu sein.
- Ich würde lieber das Send Preview Stack.vi überschreiben, so dass je nach Klasse des Aufrufers unterschiedliche VIs aufgerufen werden. Doch dabei habe gedanklich noch so meine Probleme. Ich definiere eine Nachrichtenklasse CalculatorUserMsg mit einer leeren Methode 'Send Preview Stack' (also für Override), welche ich in das Do.vi einfüge, diese Klasse muss vom AF-Message erben. Die Messageklassen der beiden Aufrufer erben dann von CalculatorUserMsg und implementieren ihre jeweiligen "Empfangsmethoden" für den Stack, wie gehabt. Ich dachte das klingt nach einem guten Plan. Doch dann schaute ich auf das VI
Das Send Preview Stack VI hat ja gar keine Inputs, anhand deren entschieden werden könnte, von welcher Klasse die entsprechende Methode nun aufgerufen werden soll. Aber durch Vererbung und Überschreiben der Methode sollte das Problem doch lösbar sein, oder? Vielleicht hat hier jemand einen Tipp für mich :-)
- Oder man baut den Ansatz vom Self Enqueuer weiter aus: Der Aufrufer übergibt nicht nur dessen Referenz, er übergibt zusätzlich auch eine Info, welche Nachricht für die Rückantwort verwendet werden soll. Hier habe ich aber leider keine Ahnung, wie man das implementieren könnte.
Wie sieht es mit einem Best Practice zu diesem Problem aus?
Nun noch eine allgemeine Frage: Es wird darauf hingewiesen, dass man im Normalfall immer die Baumstruktur bei der Kommunikation einhalten soll. Wollen zwei Akteuere also miteinander reden, muss die Nachricht im schlechtesten Fall einige Ebenen hoch bis zum Hauptakteur und dann wieder runter bis zum Empfängerakteur gereicht werden. Gibt es ein Beispiel, in dem das geschieht? Wie adressiert man dem Empfänger und wie findet die Nachricht ihren Weg? Oder bin ich hier vom Verständnis noch auf dem Holzweg?
RE: NI Actor Framework - Eine Einführung 
), da es sonst sicher schwierig wir mit nur einem VI etwas nachzuschauen.