Maybe I'm just saying this out loud to see if it makes sense...
I have some subflows that it would be nice to be able to click to do the equivalent of an inject node to start an 'alternate' flow inside the subflow. So like currently you can set "inputs" to 0 or 1, to be able to set "injects" to 0 or 1. Obviously, I could put an inject node before the subflow, and set something on the message so the subflow can do something different. However, this would need to be put ahead of every instance of the subflow, and I just want it to be available for all.
My use case is I have a subflow that does all my flow logging, and it sets the node status to what was logged. This is saved (with flow.set) and restored on a restart so I can see all the last messages on each log subflow instance. But sometimes they might be a year old, so I'd like the option to click on them to start a flow which clears that logged status. Yeah yeah I could clear them when I reset them after a restart if they're older than a year, but I'm currently just saving a string that includes day/month/time. Maybe I need to migrate towards saving JSON so in a year's time old ones can start dropping off. But maybe other people would like something similar.
Clearly the UI would be a challenge, because the clickable part of an inject node is somewhat incompatible with the input wire.
But if you don't ask, you don't get.
Just to clarify... you want to have the inject inside the subflow ? If so that is no do-able as while there is only one visual representation - there can be multiple actual instances of the Subflow - and which one would the inject go to ?
What people do instead is to use link call nodes - that call one single instance of a called flow and then return - and that small flow can have an inject if you wish.
1 Like
No that's not what I'm after. I want a button on every subflow instance that behaves like the button on the inject node. If I click on the button in the UI it runs a flow inside the subflow.
So just as you can set "inputs" to 0 (to have no input anchor on each instance) or 1 (the anchor is there), if you can have "injects" set to 0 (current behaviour) or 1 (new behaviour to display the inject-like button on each instance).
When you set "inputs" to 1 the subflow displays an "input" node to indicate where the flow starts. Similarly setting "injects" to 1 would need to display an "inject" node to indicate where that flow starts.
So very skilfully mocked up...
Then the usage would look like this:
Yuk ! 
The usual way to to that would be to just add a normal inject node with a unique topic then a switch inside to route that topic to where you want.,
I didn't say it was pretty or that I had great graphic design skills. But I have hundreds of these subflow instances, and I don't want to have to add inject nodes before all of them - if only for the ugliness. The ability to click on an instances would be an elegant solution for this use case. So maybe there's a neater way of achieving the same thing, without having to "pollute" everything with inject nodes?
EDIT: Just checked - I have 203 instances of the subflow. I like to log things.
Hi.
I am a bit of a subflow lover myself.
I sort of appreciate what you said in your last post explaining - a bit better - your situation.
But honestly, as was suggested in post 4:
use a special topic and send the messages with that topic into the subflow.
The first node is a switch which tests for that topic.
If it is the topic, it branches off to other code/nodes that do what you want.
Otherwise the message continues as per normal.
But you do understand that allowing you to click on a node to do magic stuff is out of the scope of what node-red does.
Adding inject nodes is untidy though I don't think it is a deal breaker.
I have a lot of things like that in my flows with their subflows.
So it also isn't something that is going to be done that often.
Honestly, I think what @dceejay suggested isn't a big deal.
And you could link all the nodes together and only have ONE inject node that resets ALL the subflows.
Yes, that may not be nice either, but for how often it is needing to be done..... What is the big deal?
Push coming to shove: add the inject nodes as you need them.
Taking a step back and looking at things:
Yeah, if it is that problematic maybe you need to check the subflows are better at handling these weird inputs/situations or put stuff around them to stop these situations occurring.
I appreciate it is not a sweet solution.
I have been down the nasty tasking solution quite a lot.
I've added debug stuff in my subflows and start/stop it with special inject nodes.
Yes it makes the flow a bit more cluttered, but it isn't a deal breaker. (Sorry I'm repeating myself)
