Class control greyed out

[BertMcMahan]

---

@Darin.K wrote:

Kill them all and move on before they corrupt more of your code...

---

[Darin.K]

So it turns out the clipboard was holding onto a hidden copy of my test child class.  With the child class now truly nuked I do get many errors with the default data and a grayed out control (with one of the fifty shades).  Still no luck getting it to run so it still seems that something is truly messed up in those controls.

No change to my advice.  But if I had to guess I'd say the non-class default + child class shenanigans led to this issue.  I just wish I had your luck, something that had no business working was fine.  For me, it always seems like I have something that has no business being broken which is nonetheless unable to run.

[Intaris]

I fully condone the nuclear option but a morbid fascination with the cause remains.....

Whatchagonnado?

[wiebe@CARYA]

---

@Darin.K wrote:

For me, it always seems like I have something that has no business being broken which is nonetheless unable to run.

---

I have that too. 

Probably because I assume things to just work. Even when using low level things, nested, reentrant, recursive, in (nested) subpanels, by reference, and in any\all of the combinations. It does most of the time, but definitively not always.

[_carl]

I'm fighting the same issue -- only I'm dealing with 100's of VIs that have been corrupted this way...I think the default data of the classes is holding on to old child classes that no longer exists after some library renaming, which in turn appears to be causing some load issues.

Annnyway....manually replacing everything was unpalatable, so I looked into scripting.

Turns out that I can get the class terminals to un-gray by simply updating their default values programmatically. I threw this in a quick-drop command for testing, but... will likely just run this logic on all VIs in my project...

[wiebe@CARYA]

I haven't seen this for a few years.

Are you using a recent LV version?

[_carl]

Using LabVIEW 23Q1, because, well, newer versions of LabVIEW (both 23Q3 and 24Q1) introduced an issue where building my application would crash LabVIEW...

As a follow-up...I did run a script to update all class constants and class controls/indicators with a default value equal to their data type -- and this worked magically.  The corruption I had been experiencing due to the grayed out items was resolved.  (Previously I would get a silent crash of LabVIEW when interacting with the impacted PPLs)

[wiebe@CARYA]

---

@_carl wrote:

Using LabVIEW 23Q1, because, well, newer versions of LabVIEW (both 23Q3 and 24Q1) introduced an issue where building my application would crash LabVIEW...

---

Both issues could be related? E.g. classes are disabled because of an underlying problem, builds crash because of the same problem. Maybe the LV24 builds don't crash after this fix? Of course the fix might not have fixed the underlying problem (if there is one)...

I'm going to try a few real life projects in LV24Q1 soon... I'll keep this in mind.

I'd also suspect the class mutation history. Maybe the history holds a reference to an old class that's no longer available. Not sure if it works that way. It almost never hurts to clear the history though, so it would be one of the first things I'd try. I do it regularly anyway, to speed up load time and reduce code and exe size.

[_carl]

This class corruptions I just dealt with were introduced as part of a recent refactoring effort, so I don't believe that to be the cause of newer versions of LabVIEW not building properly. (But I wouldn't be surprised if a similar corruption had happened in the past, so they could very well be related.)

As for clearing class mutation history, I had already tried that, but it didn't resolve the grayed out controls. (I too regularly run a script to clear out class mutation history for likely the same reasons as you...)