Recompute on component change state

I have a situation in my add-on where a network can be created and modified. I have a component that links nodes in a graph.

My 'link' component takes a line as input, and uses this to connect two nodes. The user could have multiple link components on the canvas at any time.

However, removing nodes from the graph is just as important as adding. But unfortunately, Grasshopper cannot trigger any code to run when a component becomes inactive (e.g. user disconnects line input from a link component, causing it to stop running). This means my network still thinks the connections that had been made by the link component are still there, when the user thinks it isn't.

I was wondering if there was a way to have some sort of controller (that I know to be running all the time) watching the canvas for state changes of the link components, and forcing something to happen if link components become inactive.

I know I can find the components:

foreach (GH_ActiveObject ghObj in ghdoc.ActiveObjects())
{
if (ghObj is ColumnLink)

{

//Do something

}
{

But which method on ghObj do I call to find out whether it is active or not? Any other flaws in this method that anyone could see? How do I ensure that my 'watcher' code runs?

Replies to This Discussion

Permalink Reply by Andrew Heumann on November 4, 2014 at 10:39am

Are the "link" components feeding directly into the network component? If so the network component will re-execute its SolveInstance method any time a link input is added or removed. Is there a reason you need to be monitoring the entire canvas in this unorthodox way?

Permalink Reply by David Rutten on November 4, 2014 at 11:07am

Disconnecting a wire should cause another solution. It will expire the component being disconnected and any components downstream of it. Is this not what you are seeing?

Permalink Reply by David Rutten on November 4, 2014 at 11:15am

To answer your second question, you typically don't need a timer, there are a lot of events you can handle that should tell you when something may have changed.

I'm also unclear about what you mean by 'active'. Are you talking about components not running because they lack a non-optional input? If so, would it perhaps make sense to mark the Line input as optional? That way your SolveInstance method will get called, even after a user disconnects the last wire going into the parameter.

Permalink Reply by Hugh Groves on November 5, 2014 at 2:22am

The nodes in my network have information attributed to them and perform some useful calculation. There is no requirement for a node to be a part of a network. As such the network is a secondary element and so I decided to make the 'link' that creates the network a downstream component. As such when it expires it does not trigger a recalculation.

Now we could say, make the link an upstream component. However to create the links I need to know about the nodes. So then I'm not quite sure how I would organise it!

In your second point you are correct David, by 'active' I meant a component not running because it lacks a non-optional input. I think your idea of making it optional and then triggering my solution when the input does not collect is a very sensible one and something I will investigate!

Permalink Reply by Hugh Groves on November 5, 2014 at 4:58am

Just as a follow up this worked perfectly for me. Great to see how a little change in thinking can solve a tricky problem. Thanks for the help David!

RSS