Public Support

Supportanfrage

Hier ist noch ein Finding von meinem Kollegen:

Guess the following can be forwarded to the developers.

It seems to have no effect when the properties of the Substream Selectors are changed during runtime. This behavior should be documented.

To reproduce the problem: Add an ADTF Property Editor to the Demo-Session/Project "Demo Substreams Session" and change the selected substream or the trigger forwarding.

Grüße,
Anja

Lösung

Der Substream Selector ist dazu, aus einen Substream (publish) ein Element zu filtern (subscribe) und als Sample Stream bereitzustellen.
z.B. zur weiterverarbeitung, wie jeder andere Sample Stream auch.
Ein Sample Stream ist eigentlich etwas statisches und fest definiertes.
Deshalb weiß ich nicht ob man gesondert an jeder Stelle dokumentieren sollte, das der Stream zur Laufzeit gleich ist.
Oder anders gesagt: Ich müsste das bei allen Komponenten dann machen.

Kann es sein dass es euch um dynamische Visualsierung zur Laufzeit geht ?
Dazu kann man das Signal View nutzen oder einen eigenen Filter.

Für sonstige Use Cases macht das ganze wenig Sinn, weil man immer den ganzen Substream zb aufzeichnet und daraus dann subscriben kann.

Aber wie gesagt, vielleicht fehlt mir auch der Use Case und die damit verbundende Erwartungshaltung, deshalb bitte geht hier nochmal ins Detail.

Aber ja, das ist eine statische Auswahl eines Substreams, da der in der Regel ja für den angehängten Folgefilter passen muss. Aber ja das sollten wir dokumentieren, mach ich in ACORE-10520 mit.