While developing with the sdk, the property of any Pin called IsConnected can be incredibly useful to gain performance advantages.
An example would be providing meta information alongside the actual calculation, which might be only be patched into in 5% of the cases, but is potentially useful for all cases during design.
However, unless I explicitly specify a plugin input as a Pin, I will not have access to that property. Atm, this rules out the most used dynamically created ones, such as ISpread<ISpread> or plugins with configurable Pin Count.
It would be nice to get access to the IsConnected in all cases, even if that just means going through a Pin-proxy Enumeration.
I tried to solve the problem with reflections into private fields, and eventually found that it treats ISpreads quite differently when they are created with different values for CheckIfChanged or AutoFlush. Then I decided, that I don’t want to go the reflection route.
That said, solving this problem would finally allow a fix for the old problems of changing pin layouts remotely. Any potential link disconnect could be detected and force the user to act on the conflict. Without a safeguard like this in place links can break silently and potentially cause massive headaches.
Thanks so far, but how would I acquire a IPin2 interface for a given ISpread<ISpread> (granted that every pin has this interface, even if I don’t see it in the pins inheritance chain nor its public members)?
I see that there are ways from both Node.cs (as an enumeration of all pins) and INode2.cs (the findpin() method) to get there, but then again, I can’t see any inheritance of a given plugin to either (they end in IPluginBase).
Therefore I assume that there is some mojo going on behind the scenes, all the extension methods for INode2 hint strongly at that assumption.
Maybe it is just me not recognizing the mechanisms in the sdk. Could it suffice to not only inherit IPluginEvaluate, but INode2 as well? What’s the consequence of doing so?
Can someone shed some more light into this dark grey box, while I try to wait patiently for @woei to clear the way?
if you have ISpread<ISpread> i guess you have the pinnname and are probably on/inside that node. IPluginHost2.GetNodePath() gives you the nodepath. IHDEHost.GetNodeFromPath(path) gives you the corresponding INode2.
my guess is that INode2 comes from the view on the patch/node-tree, in contrast to going the way from inside your plugin to the outer patch.
reason for this assumption is, because you won’t get the INode2 on initializing the plugin, not even on first preparegraph but some times after that.
Well the interface layout is probably best to explain from a historical point of view. vvvv is written in Delphi, having its own class structure of nodes and pins. The plugin interface was implemented in a way that the new classes implementing those interfaces were extending the existing ones, instead of deeply integrating the plugin interface into the existing classes. So you basically have two sorts of pins, those which implement IPluginIO and those which do not. This was all fine until someone came up with the idea of traversing the whole vvvv graph with its nodes and pins. In order to do that a new set of interfaces (IPin, INode) was added which all internal classes implemented. As woei already said, those interfaces are intended to reflect the view from the outside, whereas IPluginIO reflects the view from the inside.
IPluginIO, IPin, INode, etc. are all COM interfaces in order to be able to talk to the classes written in Delphi code. Due to that nature they are a little awkward to deal with in managed code like C#, that’s why we added a V2 version of the plugin interface (ISpread, IStream, IPin2, INode2, etc.), which wraps itself around those basic COM interfaces.
Regarding the question why IPluginBase does not inherit from INode: That’s because your plugin class is hosted inside a node (= IPluginHost = INode). So what you should be able to do is casting the plugin host to INode, from there you can ask for your pins, your parent nodes etc.