Custom enum dropdowns stay red after entries are created

hi all,

I use custom enums in my patch. When starting gamma the first time and opening the patch, all enums show red. I have a startup order to start my app patch by patch. It looks very roughly like this:

Scan folders in the filesystem
Create enums for files
Evaluate Scenes

The enums do not exist at startup. I guess that’s causing the error. You can see when they are created, but the UI element stays red.

red3

The moment I edit the patch, they all switch back to grey. If I close and reopen the patch, they are still all grey. Everything works and is buildable.

red0

I tried patching a simplified version but could not recreate the error. So I am not sure if this is my doing or gamma related. I have do admit, I use a sketchy S/R construction to send my enum datatype into my custom regions. Open to suggestions here =)

I started putting my enums into subpatches. When doing a fresh Gamma start, all enums and all patches containing enums, show red. gamma log shows no errors!

My current solution is to add and remove a random VL.Nuget or File dependency in my VL.BW library. Then all errors disappear at once. This does not happen, if I do the same for VL.nugets in the root patch.

After all nodes are grey I can close and reopen the project with all grey nodes.

My root patch references my BW.VL library, and this references a DLL with my custom enums in it.
I suspect this is where the error originates from. All “BW” nodes are definitions inside the BW.VL library.

When navigating into the subpatches of those red nodes I cannot find a single error. Just the nodes in my root show as red. I have to edit and save each patch, containing an enum, to remove the false red errors in my root patch.

“BW.Scene” is also in the same location as the other BW nodes, but it does not show as red.
Could it be that is has sg to do with the ioBoxes, holding the enum? That’s the only (enum) difference I can find, in contrast to the red nodes.

spoiler alter: my enum datatype comes via SR. I know this is very sketchy, but I found no other solution to send data into my regions without cables.

BW.Scene: contains a R node but no enum ioBox.
image

BW.Overlay: contains subpatches with R nodes and enum ioBoxes

Any chance this is not me? ;)

Have you tried adding forwards for your enums?

BTW you can also reference the csproj file.

I tried forwarding the create defaults of all my enum types, but still red after startup. I hardcoded my default enum values, so I guess that’s why mine look different from yours. How do you have that ioBox in your create? Maybe that’s the problem?

I already tried referencing my enum dll in all my vl dependencies and in my root patch without success.

image

as I understand something changed to gamma 5.x and forwarding the dependencies is no longer needed. I guess this problem is still related to: How to make my custom enum work with gammas enum nodes? - #9 by schlonzo

Regarding enums I use the example @joreg updated in the demo lib after this post.

Forward the enum itself and then create the CreateDefault operation inside that forward.

Any chance you can share a patch / zip with us?

@Elias sent it in our element room

@bjoern I don’t understand; I can drag and drop my “create default” method out of the explorer, but I get no output Pin. Or I drag the whole class; then I get a node which shows “F”. I am not that experienced with dll<->gamma workflow =)

Upcoming previews address this issue by making runtime warnings out of those messages. It was somewhat wrong to begin with that they were treated as compiler errors. By definition they might change during runtime, therefor validating them can also only happen at runtime.

The error view (Ctrl+E) should suffice to quickly sport wrong enum entries in a project.

1 Like

Super cool, thanks a lot!