VIM Enum input- Broken, but not?

[JW-JnJ]

I'm converting some of my libraries to VIM from polymorphic and I ran into a strange breaking problem I don't understand. I boiled this problem down to a few simple vi's so I don't have to upload by whole library.

First I have a conversion vim that allows a user to input string, enum, or integer. It outputs a string.

This conversion function does, in fact, accept an enum on the block diagram

That conversion is placed in a mapping function to store what I'm interested in

Now here is the fun part. Every time I drop and connect these VI's to an enum, they break. Then, if I save sometimes they unbreak, or if I save/close/reopen they always unbreak.

Since this is intended for a common use library, I really don't want this breaking every time it's used. I've tried a bunch of variants using assert type in various places. I'm not sure what I'm doing that is causing this behavior. Any ideas on what I can try?

(code is attached, sorry, LV2020 64bit)

EDIT: Every time you get it unbroken, you have to save, close and open without the enum connected and it will exhibit the behavior again.

[JW-JnJ]

Some more information. I did several "Convert Instance to standard VI".

It appears that it is broken at the Convert.vim

It claims that Convert.vim is broken due to the Integer assert on the next diagram is broken. This diagram is "ignored" so I'm not sure why that breaks the VI.

When I save this vi, the broken arrow goes away and it runs fine.

[Kyle97330 · Accepted solution]

I've had problems before with "nested" VIM files.  It seems like some of the type propagation doesn't always go through, or something.

In cases where the nested VIMs are simple ("assert" functions and conversion functions) I've started just putting the contents of the VIM I would have nested in the top VIM directly.  This removes nesting from the system and it also reduces the file size of the VIMs.  

You do lose the ability to have any updates to your VIMs propagate, which is why I only do it on the simple ones.  But I think the one you're having problems with does apply here, as it's pretty simple.

I can't try it out to verify as I currently only have LV 2018 installed and so I can't make the mapping node.

Side note, was the "trick I found on LAVA" with the enum this one?  If so, that's me, you're welcome!

[JW-JnJ]

---

@Kyle97330 wrote:

I've had problems before with "nested" VIM files.  It seems like some of the type propagation doesn't always go through, or something.

In cases where the nested VIMs are simple ("assert" functions and conversion functions) I've started just putting the contents of the VIM I would have nested in the top VIM directly.  This removes nesting from the system and it also reduces the file size of the VIMs.  

You do lose the ability to have any updates to your VIMs propagate, which is why I only do it on the simple ones.  But I think the one you're having problems with does apply here, as it's pretty simple.

I can't try it out to verify as I currently only have LV 2018 installed and so I can't make the mapping node.

Side note, was the "trick I found on LAVA" with the enum this one?  If so, that's me, you're welcome!

---

Yup, that's the trick I used. Thanks!

On that note. I collapsed the VIM nesting by one by getting rid of the integer assertion VIM and adding new type specialization cases for each integer type. It works. I guess collapsing the VIM nesting from 3 (Store/Convert/IntegerAssert) to 2 (Store/Convert) seemed to fix it. No idea why, but it does.