LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

bad type cast in nested actor

Solved!
Go to solution

Hi all,

 

I am currently trying to do a to more specefic type cast from test selection in to ext msr.  Ext msr is a direct descendant to test selection and test selection is a descendant of the actor class. I start test selection as a nested actor and then run send it a message to run this vi in image below. I get error 1448.

 

Any suggestions?

 

Thanks,

 

Matt



-Matt
0 Kudos
Message 1 of 8
(3,985 Views)

Hi Matt,

 

Turns out there's a community group dedicated to Actor Framework. You can find it here https://decibel.ni.com/content/groups/actor-framework-2011?view=discussions&start=0. I would suggest posting your question there where people more familiar with Actor Framework will be able to answer it. 

 

Hope that helps!

 

 

Daniel Parrott
Software Product Marketing - Data Management & LabVIEW
National Instruments
0 Kudos
Message 2 of 8
(3,929 Views)
Solution
Accepted by topic author Wolleee

TMSC can't be used to convert an object from one class to another, only to change the wire type. For the cast to work, the object coming into the VI has to be ext msr, so you need to launch an ext msr actor, not a test selection actor, and then this code should work.


___________________
Try to take over the world!
Message 3 of 8
(3,904 Views)

Hi Tst,

 

Im still very new to OOP and trying to wrap my head around it.  I dont think i fully understand what you mean by changing the type of wire.  In the attached image of a simple do vi, it appears that they go from actor class to log actor class? Ill explain what i was trying to do.  I was trying to downcast from test selection to ext msr without losing the object, so i could then upcast and use that reference to send message to caller of test selection.  Is that a terribly wrong way to do it?

 

Thanks,

 

Matt



-Matt
0 Kudos
Message 4 of 8
(3,873 Views)

The reason the object is being cast to the log class in that image is that they wanted to call the f(x) VI and that VI probably requires a log object as an input.

 

Here's an example which might help, assuming you are familiar with VI server, because it's the same thing there - if you get the front panel's Controls[] property, you get an array of control references. If you wire one of those to a property node, you see the properties for the Control class, but not for the actual class of the control (like Boolean Text for a boolean). To see those, you would have to take the reference and cast it down to the Boolean class, but that will only work if the reference already points to an actual boolean control. The cast changes the type of the wire from Control to Boolean, but it doesn't create a new reference and will only work if it's already referencing a boolean.

 

As for what you want, that has nothing to do with casting, but is a completely separate hierarchy. Casting is a basic concept of inheritance in OO. You seem to be talking about the actor hierarchy, which is something specific to the AF and has nothing to do with OO. In the AF you talk to the caller by using the Get Caller Enqueuer VI (or whatever it's called). If you want to talk to the nested actors, you keep their enqueuers around somewhere when you launch them (in the actor's private data, for instance) and then use that.


___________________
Try to take over the world!
Message 5 of 8
(3,857 Views)

Hi Tst,

 

So im not entirely familiar with the vi server hierachy, but im assuming that boolean is a descendant class from the control class?  When you cast TMSC then you would be down casting from control to boolean control?

 

In the first image i posted i was simply trying to down cast from test selection to ext msr, ext msr inherited from test selection.  Neither object was actually inheriting from the actor class.  Ive been reading a book on OO and have been grasping the ideas, but not sure i understand this fully yet. 

 

I much appreciate the education though.

 

Matt



-Matt
0 Kudos
Message 6 of 8
(3,827 Views)

You need to think of the TMSC as not directly as a cast to a class.

 

In OOP in LabVIEW, a class/object wire only reprecent the highst class, in a hierarchy, that can run on that wire. But what is really runing on the wire can be the parrent or child class.

Now to be able to run a method (vi) in a child class, that is spesific to that child, we need to make sure that the wire, and therefor the class that can run on the wire, is only that child class. We use TMSC for that. 

 

So for that Actor Framework and the Message classes, the do.vi in a message as Actor class parrent as input, because the do.vi is generic.

But inside a specific implementation of a message you will have a do.vi that should call a method from your Actor. So when your Actor receives the message it will execute the right method. But as this method is NOT part of the base Actor framework we need to make sure that on the wire the right child class in there.

 

If it only the parrent or another child class on the wire, then we will not be able to run the method.

 

Does this help?

Message 7 of 8
(3,793 Views)

Hi Dkfire,

 

Yes that actually does explain a lot.  It also leads me to believe what i was originally trying to do was correct, i just may have been missing something.  Is the target class the class you want to cast to or are casting from?  Also i was trying to change the wire to the child then back to the parent so i could use the read caller enqueue to message back to the caller, but i actually ended up just putting the message queue on the wire and i have an accessor to read the Message queue so i can message directly within my vi.  Is that a typical way of handling something like that?

Thanks,

 

Matt



-Matt
0 Kudos
Message 8 of 8
(3,776 Views)