Re-casting of object from control reference

[crcarlin]

I feel like this question is likely answered elsewhere, but after days of searching I couldn't find an answer. Sorry if I'm missing the answer in some obvious place.

I'm given a reference to a cluster control and told that the elements of the cluster are all children of parent class A. Using the controls[] property I get an array of the elements, and the value property of each of those elements gives a variant that can be turned into class A. At that point, all of the object oriented overriding and private data stuff works as expected.

So far so good.

But one method I call on those objects changes the private data, and I need to update the control with the updated object. There I get a runtime error because the control isn't A but some child class of A.

I think this is where Preserve Runtime Class comes into play, but since I only get a reference to work with, what do I do? This is especially frustrating because debugging probes show that LabVIEW knows the child class on the wire, but I can't see how to tell LabVIEW to cast down to the class that it knows it has.

For example, is there some way to use the ClassName property of the control to cast the object of class A into the child that the control is expecting?

[crcarlin]

Or, to put it a different way, I can read the value of a control but not write back to it.

I see why my tries at writing back haven't worked--I've casted to a different (parent) type--but it seems weird that there would be no way to write if there was a way to read.

[nathand]

Are you sure this is the architecture you need to use? It doesn't make much sense to update the value of a class front-panel object through a reference since a user will never see it. You should instead be using a DVR, which gives you a safe reference just to the data without any associated front-panel element.

The other option is "To More Specific Class" which requires a constant of the correct class as the type input.

[crcarlin]

Yeah, and if one could get the class constant from ClassName, that would solve the problem using "To More Specific Class." I haven't figured out a way to do that, though, but it sure seems like there should be.

[nathand]

Can you mock up a simplified version of what you're trying to do? It would be clearer if you show some code. Why do you not know the specific class at edit time?

[crcarlin]

This is initialization code: "Run the dynamic dispatched init.vi of every object in the referenced cluster."

But let me keep things focused: I think it's weird that I can read the object from the cluster but not write it back to the cluster. Symmetry suggests that there should be a way. Am I missing a trick, or is it really impossible? 

Either way, I'll keep DVRs in mind as a possible alternative.

[nathand]

So your trying to write to the specific control within the cluster, by reference, as a variant, and you're getting an error? What's the actual text of the error?

Really you shouldn't ever be using a front panel object this way, especially one where the user never sees the data in it. For passing data around you should use a wire. Neither a wire nor a DVR will get you the ability to pass an arbitrary cluster, though, which it sounds like is what you're trying to do. With a bit more information we might be able to suggest a better approach.

[crcarlin]

---

@nathand wrote:
So your trying to write to the specific control within the cluster, by reference, as a variant, and you're getting an error? What's the actual text of the error?

Really you shouldn't ever be using a front panel object this way, especially one where the user never sees the data in it. For passing data around you should use a wire. Neither a wire nor a DVR will get you the ability to pass an arbitrary cluster, though, which it sounds like is what you're trying to do. With a bit more information we might be able to suggest a better approach.

---

I don't have the text of the error handy, but it comes from the write value property node and basically says the given variant can't be converted to the type of the control. It happens only when the value is cast to the parent class, which makes sense.

In other words, given a control of child type,
control.value ---> variant ---> to parent ---> variant ---> control.value     failes with the error

control.value ---> variant ---> to child ---> variant ---> control.value       succeeds

So a solution would be a way to cast to the child instead of to the parent. LabVIEW knows what class the control contains; it is listed in a number of places from the ClassName property through the probe window. The problem is I know of no way to bridge the gap from "LabVIEW knows what class this thing is" to "have LabVIEW cast the variant to that class."

I completely agree that I shouldn't have to ever be using a front panel control this way, but I don't want to get sidetracked into talking about the shortcomings of LabVIEW that have required such a use. Suffice it to say, that is the assignment.

[nathand]

I mocked up what I understand you to be doing, and I'm not seeing an error (LabVIEW 2012). Does the attached image and project accurately reflect a simplified version of your code? Can you explain in more detail what you're doing, or modify this example so that it generates the error that you see? Here I have a cluster containing two class controls, where Class 2 inherits from Class 1. The code iterates through the control references within the cluster, converts the variant to Class 1, runs a dynamic dispatch method, then writes the object back to the control reference value property. This does not cause an error, and the dynamic dispatch works properly.

Also, if you're running into what you feel is a limitation of LabVIEW, you might want to post a suggested improvement on the Idea Exchange.

[crcarlin]

Oh! It's very interesting that this worked for you since it's nearly identical to what i was doing here. I just have a complication involving other datatypes in the cluster.

When I have time I'll have to play with this some more and see if I can narrow down exactly what makes it fail over here.