Register C# node for forced execution

[radumg]

Dynamo version

1.2.1

Operating system

Windows 10

What did you do?

Made a class (singleton pattern) in a zero-touch library, which can

• add items to (SingletonClass.Add())
• update those items (SingletonClass.Update())
• display all its items. (SingletonClass.ListAll())

Steps to reproduce

No elements in singleton class yet

Added a new item to class's static list - ListAll node output should update

Add a new ListAll node to workspace & its output is updated

What did you expect to see?

The output of the SingletonClass.ListAll() be updated after a node like SingletonClass.AddItem() has been added to Dynamo Workspace and executed.

What did you see instead?

However, the output of the SingletonClass.ListAll() method only gets updated if I replace this node on the canvas or re-open the file. This is because the node has no input (returning the value of the Singleton's static property) and therefore its refresh is not triggered & instead cached by Dynamo.

Question

My question is if there is any way of forcing this particular node to execute :

• whenever anything in the Workspace changes (is there an event I can subscribe/register to for example ?)
  • or if not, at least at a particular interval (and not have to set .dyn to Periodic

[teocomi]

If you write a :NodeModel class you can use OnNodeModified(); to expire the node and force its execution, but I'm afraid there is no way to do it with a zero-touch library...

[radumg]

Thanks @teocomi - was afraid it can't be done from Zero-touch. Would this be achievable then as a Dynamo extension ? Very little documentation out there for Dynamo extension development (can you help @racel ?) and they also can't be distributed through package manager currently afaik?

To give a bit more detail on what I'm trying to achieve, it's a "wireless" Dynamo, which allows the use of dropdowns to retrieve an input's value. The flux.io plugin functions similarly but suffers from the same problem from what I could gather.

[teocomi]

You can find some samples here: https://github.com/DynamoDS/DynamoSamples/tree/master/src/SampleLibraryUI

[Racel]

@radumg - What do you mean by Dynamo "extension"? I'm not sure if we have documentation on that. If you need more info check out http://dynamobim.org/developer/ for resources.

Regarding "wireless" nodes, have you checked out the Prorubim DS Common Kit package? I think it might do what you want, but only works with basic node inputs...Here's a forum post where it is discussed: https://forum.dynamobim.com/t/setvar-getvar/4791/2

@mjkkirschner - any ideas?

[mjkkirschner]

@radumg - I have a PR out (has been for a while) to letting the package manager distribute extensions.

A Dynamo Extension can basically do anything as you can construct your own DynamoModel - though you can probably also do this with a UI node.

[radumg]

Thanks @racel & @mjkkirschner for picking this up.

@Racel , other than the samples @teocomi kindly posted above, I couldn't find any documentation on Dynamo Extensions, which is why I wanted to put it on your radar : would be great to get more guidance on these and then include them in developer resources page.

@mjkkirschner , saw that PR 👍 and was basically wondering if there is any documentation to go with it. For example, does an extension follow the same structure as a package and hence need a package.json, or would it be something more like an extension.json ? If the former, any special parameters that need to be defined inside ?

[radumg]

In terms of functionality, @Racel was spot on with the Prorubim DS Common Kit suggestion, thanks for the great tip 👏 I'm basically trying to build that but with the ability to handle any object type.

This is where I've gotten to in terms of CRUD operations & class structure (name tbc, originally had it as Teleporter).

If I hook my node up to the ForceChildrensEval node from Prorubim, it happily executes every time, as expected.

So I will study up how it was done in that package and report back.

As feedback, it would be great to have something as simple as an attribute annotating a method to do this. Something like [ForceExecutionEveryTime] would also fit in with the way things are done currently (or use a property on the NodeModel like CanUpdatePeriodically).