OpenG Variant Configuration File - strange behaviour with TypeDef cluster, possible VI corruption??

[Blokk]

A colleague just came, and he told me he discovered a strange behavior when he played with OpenG config file VIs, and he does not understand what is going on. Me neither 🙂 I reproduced the problem in a small VI. Note that, if I create a new VI, with EXACTLY the same functions inside, I do not see this issue! VI file/typdef cluster corrupted in this VI instance???

I attached a zip file which contains 3 files:

1. Config_Data.ctl
2. Read_config.vi
3. testini.ini

How to reproduce the problem (VI corruption/bug??):

1. Unzip the sandbox folder to your disk
2. Open the Read_config.vi
3. Browse out the testini.ini for the "configuration file path" control. Before running the VI, open the ini file, you can see there is data in it!
4. Run the VI.
5. Surprise!!! The output shows default values, and NOT what it should!!! (see the snippet below, made after this execution step)
6. OK, lets be sure this typdef is the one which is in the same folder as the VI: open typdef, check properties, it shows proper path!
7. Ok, now delete this Typdef cluster constant from the BD of the VI.
8. Right click on the BD, go to "Select a VI...", browse the typdef control, and drop it into the BD of the VI.
9. Connect the wires back.
10. NOW, everything works as it should! We get the ini file data as output!

What is THIS? 😄

[LabViewTinkerer]

To get this straight:

You delete the typedef from the BD, then you insert it again and it works?

I see two possibilities here:

1. Bug in LabView = Black Magic, nobody knows

2. also bug in LabView, but the new inserting of the Typedef causes the compiler to rerun. Let's assume it has been compiled last under LV16 or and is now used in the BD. It isnt compatible with LV17 for some black magic reason, but the recompiling causes it to work.

That would be my guesses.

[Blokk]

---

@LabViewTinkerer wrote:

To get this straight:

You delete the typedef from the BD, then you insert it again and it works?

Correct!

I see two possibilities here:

1. Bug in LabView = Black Magic, nobody knows

2. also bug in LabView, but the new inserting of the Typedef causes the compiler to rerun. Let's assume it has been compiled last under LV16 or and is now used in the BD. It isnt compatible with LV17 for some black magic reason, but the recompiling causes it to work.

The VI and the ctrl was from a project, also coming from LV 2017.

That would be my guesses.

---

I attach the original project zipped up. Recently I am tutoring a colleague, and told him to play with config files. He sent me his work for review, and he also asked me why the ini file write works, but the read back step not, despite I showed him some time ago how easy this operation using OpenG is...

edit: in my OP, I attached that sandbox folder, because I wanted to minimize file numbers, but keep the behavior. I simply copied out the ctrl and the Read ini VI, then disconnected them from the library, and linked the ctrl to the VI. So that was all what I did, nevertheless, the behavior also present in the original zip!