Class control greyed out

[deceased]

Today, I found that all of the class controls (and indicators) in all of the VIs for a certain child class in my project are greyed out like in the picture below. 

The code still functions fine. I have resaved the class, and entire project, but the greyed out icons remain.

I can replace them with the class control from the project, then they are back in full colour.

Its not causing any issue (that I am aware of), but I just cant figure out what it means, or how to remedy it without deleting and replacing the offending controls.

Has anyone seen this before?

[wiebe@CARYA]

Is the class locked for editing?

That would disable the controls\indicators IIRC. If so, go to the class, and right click, then select "Why is this library locked"? That should give you some information.

[deceased]

---

wiebe@CARYA wrote:

Is the class locked for editing?

That would disable the controls\indicators IIRC. If so, go to the class, and right click, then select "Why is this library locked"? That should give you some information.

---

Wiebe, thanks for the response, the class isn't locked. (I am familiar with that pain from trying to share classes between PC and RT in the distant past).

Any other thoughts?

[Intaris]

They also have non-default values (Black border). Maybe the two are linked? They didn't used to be greyed out in that case, but maybe this is new?

[deceased]

---

@Intaris wrote:

They also have non-default values (Black border). Maybe the two are linked? They didn't used to be greyed out in that case, but maybe this is new?

---

Wow, I didn't know that was a thing. I can't even think how that can be achieved.

I tried the obvious reinitialise to default, it didn't help, but you may well be correct that they are linked

Thanks for the input.

[Darin.K]

---

@deceased wrote:

---

@Intaris wrote:

They also have non-default values (Black border). Maybe the two are linked? They didn't used to be greyed out in that case, but maybe this is new?

---

Wow, I didn't know that was a thing. I can't even think how that can be achieved.

I tried the obvious reinitialise to default, it didn't help.

---

The phrasing 'non-default values' is a bit misleading as it misses a level of non-defaultness.  The black border indicates that the default value of the control is not the default value of the class.  Reinitializing to default is only going to give you the non-default default, you need to replace the control or paste in the class default data and make it default.

If every class constant with the default data had a memory copy it would be a potential memory hog.  Instead, all constants with the class default point to a single copy of the default data, and those that do not are marked, sort of like a buffer allocation warning.  I am sure that it is deliberately ugly because storing these non-default values in a constant can lead to some sticky situations when the class data or defaults change.

Does the graying out persist across restarts?  LVOOP can really mess with the IDE and it just needs to start over sometimes.

[wiebe@CARYA]

---

@deceased wrote:

I can't even think how that can be achieved

Open a subVI, run the main. Make class control's value default. Now the default value is non-default class data. Reinitialize will restore to that value, not to the class' default data.

This feature can be very convenient BTW. If it changes in any way, it will make very good use cases impossible. It should not grey out the controls for sure. If it's related, it's a bug AFAIC.

[Intaris]

Thanks Darin for clearing that up.  Yes, an Object "Default" and a Control "Default" is not neccessarily the same thing (it can be but generally isn't and if it is, it's only by coincidence).

Sorry for not being clear about that. Still, I'm not sure it's actually related to the greyed out issue at hand......

[Intaris]

---

wiebe@CARYA wrote:

---

@deceased wrote:

I can't even think how that can be achieved

Open a subVI, run the main. Make class control's value default. Now the default value is non-default class data. Reinitialize will restore to that value, not to the class' default data.

This feature can be very convenient BTW. If it changes in any way, it will make very good use cases impossible. It should not grey out the controls for sure. If it's related, it's a bug AFAIC.

---

Of course it's useful. And it isn't supported in NXG......

[deceased]

---

@Darin.K wrote:

---

@deceased wrote:

---

@Intaris wrote:

They also have non-default values (Black border). Maybe the two are linked? They didn't used to be greyed out in that case, but maybe this is new?

---

Wow, I didn't know that was a thing. I can't even think how that can be achieved.

I tried the obvious reinitialise to default, it didn't help.

---

The phrasing 'non-default values' is a bit misleading as it misses a level of non-defaultness.  The black border indicates that the default value of the control is not the default value of the class.  Reinitializing to default is only going to give you the non-default default, you need to replace the control or paste in the class default data and make it default.

If every class constant with the default data had a memory copy it would be a potential memory hog.  Instead, all constants with the class default point to a single copy of the default data, and those that do not are marked, sort of like a buffer allocation warning.  I am sure that it is deliberately ugly because storing these non-default values in a constant can lead to some sticky situations when the class data or defaults change.

Does the graying out persist across restarts?  LVOOP can really mess with the IDE and it just needs to start over sometimes.

---

Darin, thanks for your response.

Yes, it has persisted across re-starts, I even tried opening on colleague's machine. 

There's only a handful of methods in this particular class, so its not going to be a problem to replace all. 

That said, it's still not at all clear what caused it to get into this state in the first place.