Getting more specific class automatically

[Gub156]

Hello everyone,

I'm using a VI in which I have an array of different types of refnums. I'd like to know if there's a way to get the most specific class “automatically”, i.e. without having to test the class name or ID and then condition it (see attached VI).

Thanks for your help!

[paul_a_cardinale]

Sorry, no.

[raphschru]

If you have generic objects as an input, you cannot avoid casting them to a more specific class to use their specific properties.

You can kudo this (old) idea that aims to simplify want you want to do:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-vi-server-reference-type-as-case-selector/idi-p...

Regards,

Raphaël.

[paul_a_cardinale]

---

@raphschru wrote:

If you have generic objects as an input, you cannot avoid casting them to a more specific class to use their specific properties.

You can kudo this (old) idea that aims to simplify want you want to do:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-vi-server-reference-type-as-case-selector/idi-p...

Regards,

Raphaël.

---

You could create an XNode that is a case structure with that functionality.

[Kyle97330]

---

@paul_a_cardinale wrote:

---

@raphschru wrote:

If you have generic objects as an input, you cannot avoid casting them to a more specific class to use their specific properties.

You can kudo this (old) idea that aims to simplify want you want to do:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-vi-server-reference-type-as-case-selector/idi-p...

Regards,

Raphaël.

---

You could create an XNode that is a case structure with that functionality.

---

On the off chance you're thinking of doing just that, maybe spend 10-15 minute listening to Darren Nattinger tell you not to use them first:

https://youtu.be/HKcEYkksW_o?t=589

(That is a link to his "LUDICROUS ways to Fix Broken LabVIEW Code" presentation from 2022 at the timestamp he starts talking about xnodes)

[paul_a_cardinale]

---

@Kyle97330 wrote:

---

@paul_a_cardinale wrote:

---

@raphschru wrote:

If you have generic objects as an input, you cannot avoid casting them to a more specific class to use their specific properties.

You can kudo this (old) idea that aims to simplify want you want to do:

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-vi-server-reference-type-as-case-selector/idi-p...

Regards,

Raphaël.

---

You could create an XNode that is a case structure with that functionality.

---

On the off chance you're thinking of doing just that, maybe spend 10-15 minute listening to Darren Nattinger tell you not to use them first:

https://youtu.be/HKcEYkksW_o?t=589

(That is a link to his "LUDICROUS ways to Fix Broken LabVIEW Code" presentation from 2022 at the timestamp he starts talking about xnodes)

---

Well, I wasn't thinking of doing it.  But also, at my age, someone's opinion about what I should and shouldn't do, doesn't carry much weight.

[paul_a_cardinale]

Maybe I should invent a malleable XNode 🤪 (*.xnodem)!

[Hooovahh]

---

@Kyle97330 wrote:

---

On the off chance you're thinking of doing just that, maybe spend 10-15 minute listening to Darren Nattinger tell you not to use them first:

https://youtu.be/HKcEYkksW_o?t=589

(That is a link to his "LUDICROUS ways to Fix Broken LabVIEW Code" presentation from 2022 at the timestamp he starts talking about xnodes)

---

Wonderful presentation that I've been meaning to watch more of. I left this comment on the video:

Darren's presentation is well thought out, full of useful things, and valuable for any LabVIEW developer. And I understand his perspective of wanting to help LabVIEW developers with their individual issues that need fixing. So telling developers to avoid a major issue in LabVIEW is a good idea.

But I would rather see LabVIEW itself be better. All of these things that are broken within LabVIEW should ideally be fixed. Avoiding XNodes, VIMs, PPLs, and possibly Class Property Node Clusters, should not be something I have to worry about. These are features of the language, and should work well together, not cause crashes, and not cause build errors. I understand NI has limited resources, and they can't be expected to fix all issues. That's why presentations like this are helpful. But if NI is serious about reducing the amount of support tickets associated with VIMs, I'd suggest investing time in fixing the corner cases with VIMs. If XNodes are corrupting VIs in a PPL, I'd suggest creating a bug to fix why that is happening, not just to create a bug for when XNodes are used in the Actor Framework, and a bug to fix why the search feature is crashing with corrupted VIs.

I have personally filed bugs with NI regarding nested VIMs, when used in a built application. Once they discovered that a VIM replaced with a static VI fixed the build they closed the issue. I strongly suggested they try to fix this issue for everyone, and not rush in closing out my issue.

---

EDIT: Oh and Darren does express some of these same comments earlier in the presentation, so I don't want it to seem like Darren isn't trying to make LabVIEW better.  He specifically says people at NI might not be happy with him presenting it, and shining a light in LabVIEW's issues.