Share Enum from Plugin to Plugin

i’m trying to share a dynamically populated and uniquely identifyable enum with another plugin. the second plugin “GetState” has access to anything coming from the main class based in AutomataUI via a Pin input.

what i tried so far in GetState, two ways, two problems…

  • i can’t dynamically create the enum pin based on the original enum ID at OnImportsatisfied (too early) nor at any other point in time since i’ get an division by zero exception in utils.

  • then i tried to use an enum defined in getstate and fill the list with data coming from the incoming main class, this works but it should only be updated on change…leading to another problem. i can’t receive events through the Pin connection. neither “IsChanged” nor events i defined myself in AutomataUI.

what is the best practise to have a plugin share its dynamic enum pin via a Pin connection. is there something obvious i missed ?

hard to guess without seeing any code

did you set them up using the same EnumEntry?
if so you should be able to call
VVVV.PluginInterfaces.V2.EnumManager.UpdateEnum("MyEnumName", defaultEnum, stringArrayOfEntries);
which updates the enum all over the place

alternatively, since you have access to the main Automata class from the GetState plugin. let the main class have an event where all the connected nodes can subscribe to. no need to actually pass anything around the node pin connection

hey woei, thanks for trying to help.

i try to use the same EnumEntry since i’m aware this would be the easiest way to have all nodes in sync. Therefore i try something like this, when the cable is connected…

this is what i do first, create the blank enum and the input pin for the automata class

protected IDiffSpread EnumState;

    public Pin<AutomataUI> AutomataUI;

and then register the connect event

     public void OnImportsSatisfied()
        AutomataUI.Connected += Input_Connected;

and then i try to create the enum based on the incoming class

private void Input_Connected(object sender, PinConnectionEventArgs args)
        EnumState = FIOFactory.CreateDiffSpread<EnumEntry>(AutomataUI[0].attr);

i just take the Attributes containing the EnumEntry from the incoming class and i get “System.DivideByZeroException” in VVVV.Utils.dll.

concerning your second idea, i’m not sure if you fully understood the first post or i misunderstood you. each automataUI node instance is unique and the GetState node should only work with the automataUI node its connected to since each enum list is unique too. therefore i have to respect the connection in some way.

guess this is your input pin, which just fired the connected event?
because it will not yet be set, when you are notified by the connected event.

guess the easiest way would be to set an internal flag, which you process on evaluate. only at that point you are sure, that the input is already copied from delphi to c#.
if you need it immediately you will have to traverse the connections upwards via args.OtherPin until you find an automata node

you are right, that’s what i thought and i was looking for a way to solve that

i tried that. i can look for “IsConnected” in the evaluate loop but only update once something changed hence wait for an event fired by AutomataUI through the cable. I failed receiving events such as “IsChanged” events from DiffSpreads and i don’t receive events which i defined myself. All events work within the master node but not through the cable.

i.e. i have a StatesChanged event which works in the automataUI node written like

this.StatesChanged = () =>
FLogger.Log(LogType.Debug, “State Changed”);

but when i try to subscribe to it in GetState like

AutomataUI[0].StatesChanged +=

then it doesnt work. no exception, just no events firing although it does in the master node. the question is, how do i subscribe to events through a pin ? or is this just not the way to do it.

can you elaborate on this ? traverse upwards. is there an example of this technique somewhere ?


i was thinking too complicated i guess. a simple bool variable in the parent node was enough to inform the child about the change of the enum list.

probably even less code then all my trial and error mess with events.

indeed ! thanks a lot

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.