Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Siblings both need Parent Actor's Data

This may be more of an OOP question but I thought I would ask here as it pertains to AF.

I have a Child of Actor.lvclass calles Intrument (INSTR). INSTR has children VIEW and CONTROL. When I want to launch VIEW from CONTROL, I want to make sure VIEW gets all of INSTR's current data. The picture below shows my problem. Since I am selecting VIEW from a file name it's wire will be of type LVObject until run-time when it selects the correct class.

I thought of placing a ToMoreSpec Class into the LVObject reference but that will screw up the selection of the Actor Core wont it? There must be a way to do this without making a case structure holding all possible VIEW objects, right?

Untitled.jpg

0 Kudos
Message 1 of 9
(6,562 Views)

Hey jbjorlie,

The short answer is that you cannot do what you want in the way you want to do it.  Your approach is admirable and not an uncommon mistake in folks learning OO.

The wire carying CONTROL class can never be anything else but a CONTROL.  I know you performed a To More Generic on it, but LabVIEW at runtime will still know that the actual datatype is CONTROL.

So, the To More Specific (cast) is attempting to cast the wire into something you were hoping would be the class you read in.  Well, first, the only thing we can cast the wire into is a class in the derivation chain between INSTR and CONTROL.  Lets say you had a deeper inheritance tree.  CONTROL derives from GenCONTROL which derives from INSTR.  So we could cast the wire to GenCONTROL or back to CONTROL.

Also, the 'specific class reference' terminal of To More Specific (top right terminal) will always be the same data type as what is coming in.  As this is happening at design time, what is coming in is an LV Object despite the fact that you told Get LV Class Default that it sould read in a VIEW class.  The read does not happen until runtime so while in design time, it is only known to the compiler as a LV Object.

For it to be useful, you actually have to cast it into something you know it should be.  For instance, let's assume we are loading a Last Ack message, I would do something like this:

ScreenHunter_04 Feb. 29 23.44.jpg

This makes no sense in the AF (you would not call the Do this way), but I wanted to show you the syntax.  To be a bit more generic and a true plug-in approach:

ScreenHunter_05 Feb. 29 23.48.jpg

Remember because of Dynamic Dispatch, the method called will be Last Ack's.  In you case, the Message constant wired to the Target terminal would be a INSTR and the path would be for your VIEW class.  And the Do would be the Launch Actor.

I am sorry to say that the 'only' way to get the INSTR level data that was in CONTROL on your original diagram into the newly created VIEW is to perform Read and Writes of each property.  I quote only because there are other ways depending on how data is stored and methods are scoped, but for now lets keep it simple.

Message 2 of 9
(4,346 Views)

Kurt left out one interesting tidbit ... often in OO, it is better to look at containment rather than inheritance for situations like this. You have this CONTROL object and you're creating a new VIEW object. In some situations, it would make complete sense to simply add a CONTROL to the private data control of VIEW and just copy the whole object in there in its entirety. Basically, instead of CONTROL being an actor object, you'd make it just a block of data that various actors consume.

I don't know how much this applies to your case, but I figured I'd mention the possibility.

Message 3 of 9
(4,346 Views)

As always you guys are incredibly helpful. Many thanks.

I had been thinking of inheritance as kind of a "path" where you could strip off the last layer and put on a new one inheriting all the parent's state inforation and losing the old child's. In actuality, even though a car is a vehicle I cannot strip a truck down to a vehicle and then make it a car keeping the same tires.

AQ's answer helps me solve the current problem and Kurt's helps me with another. I had no idea I could upcast | downcast something and still get the child's DD! That makes a world of difference when you need to put dynamic sub-VIs into a Do.vi. I was sending the VI's Actor with the message thinking if I used the Actor terminal of the Do.vi it would not work! I guess I should have looked through the examples better...

Message 4 of 9
(4,346 Views)

> I had been thinking of inheritance as kind of a "path" where you could strip off the last layer and put

> on a new one inheriting all the parent's state inforation and losing the old child's. In actuality, even

> though a car is a vehicle I cannot strip a truck down to a vehicle and then make it a car keeping the

> same tires.

That may very well be the single best analogy I've ever heard for this. I will be appropriating that the next time I have to explain this problem. 🙂

And, for the record, the To More Generic primitive is a TOTAL AND COMPLETE NO-OP. It does nothing at runtime. Nothing. The data is unchanged... it only changes the type of wire that the data is traveling on in the editor environment. The only reason the primitive exists is because people want a way to avoid coercion dots when they wire a child class wire to a parent class terminal. Which gets back to my long-standing desire for three different styles of coercion dots. 🙂

Message 5 of 9
(4,346 Views)

I kudo'd the idea.  I was going to mention that I had never used the To More Generic; so I am glad you indicated it was a no-op.

In reading the forums, it seems the most common mis-understanding by newcomers to LVOOP is the conversion of one class to another.  Often they have a Car object and want to make it into a Two-Door Car for example.  I agree, jbjorlie, your's is a great analogy.

0 Kudos
Message 6 of 9
(4,346 Views)

To fully spell out jbjorlie's analogy:

Tire Movement.png

0 Kudos
Message 7 of 9
(4,346 Views)

That's great! Glad you guys undestood what I was saying with my poorly constructed paragraph up there

Kudo'd that dot idea too & I'm happy to have the inheritance cleared up in my mind. Now the only AF roadblock I see is finding that one message vi (in over a hundred now) that's broken. Surely there's an easier way than opening each one but I don't see any documentation on it...perhaps I need to look through the forum more.

BTW, where would I post a 2012 AF question?

0 Kudos
Message 8 of 9
(4,346 Views)

jbjorlie wrote:

BTW, where would I post a 2012 AF question?

Beta forum.

0 Kudos
Message 9 of 9
(4,346 Views)