Nun, das Übersenden von einfachen Eventquellen ist sicherlich schon sehr nützlich, wenn man wie im Beispiel 1 viele Quellen zum Beispiel in eine CoreCell übertragen möchte.
Es gibt aber auch Eventquellen, die mehrere miteinander verknüpfte Daten senden und empfangen:
MouseArea, XY, EventTable, SnapValueArray, SystemInfo. Natürlich kann man jeden Ausgang und Eingang als eigenständige Eventquelle bzw. eigenständiges Eventziel sehen und wie im ersten Beispiel beschrieben mit verschiedenen identifiers verwalten. Eleganter kann es aber sein, wenn man solche Daten zu einem Block zusammenfasst, zum Beispiel um beim routing sie unter einem identifier laufen zu lassen.
Das Beispiel 2 beginnt zunächst mal völlig harmlos. Durch kleine Veränderungen kommen wir hoffentlich den Geheimnissen des frameworks etwas näher.
Wir wollen durch einen Triggerevent fünf Werte in einem Block übertragen. Diese sollen innerhalb der erzeugenden CoreCell den Status der Gleichzeitigkeit haben. Es ist weniger erstaunlich, dass man diesen Status innerhalb der CoreCell erreichen kann; umsomehr erstaunlich ist es aber, dass dieser Status über einen sequentiellen Bus in primary zu einer anschließenden CoreCell übertragen wird, so dass diese in der empfangenden CoreCell wiederum den Status der Gleichzeitigkeit haben.
Zunächst beschäftigen wir uns aber nur mit der Sendeseite.
Die Daten selbst lauten zum Beispiel (1, 1.1, 1.2, -1.3, 2.4). Ich nehme an, dass ihr mittlerweile das Skript über multiplexing zum vierten Mal durchgelesen habt und schon wisst, dass man dem Bus irgendwie den identifier id und die Anzahl # der Daten mitteilen muss. Also im Prinzip lautet der gesamte Datensatz (id, 5, 1, 1.1, 1.2, -1.3, 2.4). Dies ist nicht ganz richtig, wie wir noch sehen werden, aber lassen wir uns überraschen.
Hier ist der grundsätzliche Aufbau von der Primary-Seite: Ein Button als Trigger, die EventCoreCell, die die Werte festlegt und der Eventmonitor zur Kontrolle des Busses.
Wir bemerken, dass an die EventCoreCell ein chainIterator angeschlossen ist, d.h. innerhalb der CoreCell läuft also ein Iterationsprozess ab.
Der Trigger wird zweifach benutzt: zunächst innerhalb der CoreCell und dann noch im chainiterator. Etwas komisch, wo man doch annehmen könnte, dass man nur durch einen Event den chainiterator anstoßen müsste.
Schauen wir uns mit dem Eventmonitor den Datenblock an, so erkennen wir erstaunt, dass dieser länger ist und einen zusätzlich Event mit dem Wert 31 mitführt.
Fortsetzung folgt
ciao herw
und nur den wert des Kabels mit dem Mauszeiger ausgelesen hab.
