Type Def'ed Cluster Appears Void?

[Hooovahh]

I was working with some hardware abstracted classes, and building them into VIPM packages.  The source was fine and the build seemed fine.  Then I go to drop them on my palette and an array of a cluster appeared as if it was a broken wire...sorta.  Just watch the video:

https://www.screencast.com/t/XwSaRtSFY

After that I closed and re opened LabVIEW and things were fine again so I believe it to be something I did during the video that forced a compile of that typed control which might have been the issue.  Since then I haven't been able to reproduce this issue.  Anyone seen this before?  This is in 2017 SP1 F1 32-bit Windows 7 x64.

[Ben]

That video tried my patience... not used to coding that slow.

The message about the "lock" reminds me about not being able to move VIs around in a Library (to a private scoped folder for example) while an application is currently open and running on a RT target that uses types in a library under the Windows side. Not sure what I can say beyond that observation.

It would be very interesting if you could re-create or trap that issue.

Ben

[Jacobson-ni · Accepted solution]

I remembered something similar to this and it looks to be tied to CAR 654251 which has the description "SubVI with cluster containing a class has a Void Wire when initially added to LabVIEW Palettes through VI Package Manager (VIPM)". It sounds like what you are running into so if you want to try any of the listed workarounds they are:

1. After installation of the package, switch the order of elements in the cluster.
2. Add the SubVI directly from disk rather than through the LabVIEW Palettes. The subVI behavior will depend on where the SubVI was first added from (disk or palette).
3. Save the VI you create containing the SubVI, close it, then reopen it. (You mentioned closing LabVIEW fixed the problem)

The person who originally ran into this chose to disable mass compile after installation for the VIP and then write a post-install VI to swap the order of the elements in the particular cluster (make sure you aren't using the regular unbundle int hat case).

[Hooovahh]

That video tried my patience... not used to coding that slow. 

---

I'll fast forward it next time.

I remembered something similar to this and it looks to be tied to CAR 654251 which has the description "SubVI with cluster containing a class has a Void Wire when initially added to LabVIEW Palettes through VI Package Manager (VIPM)". It sounds like what you are running into so if you want to try any of the listed workarounds they are:.

---

Yes this sounds exactly like what I'm seeing.  Those steps sound like a pain to automate.  Especially from a general building process where it isn't know if this will be an issue until it is tested.  Package building for me follows the same rules from package to package in terms of pre/post build/install/uninstall actions and making something custom fragments the code base a bit.  I'll see what I can get to work.  Thanks alot.

[JÞB]

---

@Ben wrote:

That video tried my patience... not used to coding that slow.

Ben

---

That bit of bragging almost demands a "Jing" to back it up.  From anyone else , I'd call it B.S.  but, let's see the master at work and teach us.

[Ben]

What? The Smiley-tongue was not enough to indicate sarcasm?

Ben

[JÞB]

---

@Ben wrote:

What? The Smiley-tongue was not enough to indicate sarcasm?

Ben

---

Nope, missed the emoji.

[brentjustice]

Hooovahh, did you have any luck here?

I think I'm just now encountering this exact issue.  I  can't seem to find a graceful solution.

[Hooovahh]

Okay well one good thing is I did archive several of my Jing videos and put them on Youtube and this happened to be one of them.

https://youtu.be/4e3Rz8cg1hU

Since I haven't seen this in recent versions of my reuse library I'd say either a fix came in with newer versions of VIPM, or newer versions of LabVIEW.  I've primarily been using 2020 SP1, but 2018 also uses these libraries.  The original issue was mentioned using 2017.

[brentjustice]

Bizarre,

I'm using LV2020 SP1 32-bit.

Your video and description match exactly what I'm seeing.

I rebuilt my code by swapping the offending cluster with a class solely for data encapsulation.  This yielded success.

I'll poke a bit more, but the bug definitely still appears to be present, atleast in some capacity.