[feature request] Stop specific broadcasters firing at on init
-
@Christoph-Hart said in [feature request] Stop specific broadcasters firing at on init:
yeah why not. I noticed that the setBypassed() method doesn't have an impact on the initial callback firing, so that would be my preferred fix
Would I need to manually unbypass it when I want it to fire?
-
@d-healey yes but you could just reactivate it after the listener has been added. There's also a way of doing this with a scoped statement, but the current implementation will send a listener call when it goes out of scope.
The syntax then would be:
const var bc = Engine.createBroadcaster({ "id": "bc", "args": ["component", "value"], "tags": [] }); { .bypass(bc); // a scoped statement that will temporarily bypass the broadcaster. bc.attachToComponentValue("Button1", ""); bc.addListener(0, "print", function(component, value){ Console.print(value); }); }
-
@Christoph-Hart Aha clever - so it's just a matter of fixing the bug in the current behaviour?
-
@d-healey this and adding a parameter to the bypass statement that controls whether the messages are sent when it goes out of scope.
-
Why not just set a global boolean - BC_READY = False - and then have all listeners have a check for True before they're allowed to process?
I think Christoph's solution is probably okay. Just curious why this is a big deal really ?
-
@Orvillain Yes a flag solution is the current workaround, but nobody likes flags. You end up with a list of variables whose only purpose is to be gatekeepers. The bypass feature is a much cleaner and self contained solution.
-
Alright, done. I added a new parameter to the
.bypass()
statement so this is the working example now:const var bc = Engine.createBroadcaster({ "id": "bc", "args": ["component", "value"], "tags": [] }); { .bypass(bc, false); // a scoped statement that will temporarily bypass the broadcaster. bc.attachToComponentValue("Button1", ""); bc.addListener(0, "print", function(component, value){ Console.print(value); }); }
-
@Christoph-Hart Have my babies.
-
@Orvillain It's also not always possible to tell if a broadcaster is being called at startup…which doesn't sound right, but there are edge-cases.
-
@Christoph-Hart Nice, going to give this a try now.
@clevername27 said in [feature request] Stop specific broadcasters firing at on init:
It's also not always possible to tell if a broadcaster is being called at startup…which doesn't sound right, but there are edge-cases.Can you make an example?