LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Child class labview different datatype

I have a parent with a method which accepts a string. Now I want to know is it possible to create a child method which does accept not a string but a numeric datatype for example? 

I believe it is not. But I ask anyway just to be sure... 

0 Kudos
Message 1 of 8
(5,890 Views)

@WouterG wrote:

I have a parent with a method which accepts a string. Now I want to know is it possible to create a child method which does accept not a string but a numeric datatype for example? 

I believe it is not. But I ask anyway just to be sure... 


Well you believe incorrectly!  When you create you method vis enable dynamic dispatching
dynamic dispatch vi's must have the same con pane layout (and they are limited to the 4-2-2-4) pane but its actually pretty easy to do.  Check the shipping examples


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 8
(5,886 Views)

Yes I know... but why I get this error then?

 

This VI doesn't match other VIs in the method, Connector Pane Terminal(s) are different. All VIs that implement a method of a LabVIEW class must match Connector Panes. To correct this, compare Connector Pane of both this VI and the VI of an ancestor class that implements this method.

 

 

Strange.png

 

The connector panes are 100% equal. (Also with required, recommended and optional settings on the in- and output)

0 Kudos
Message 3 of 8
(5,884 Views)

You can not create an override method with different data types. The panes must match exactly. If you create another method tha invokes the method, it will work.

0 Kudos
Message 4 of 8
(5,878 Views)

Oke, well that is what I meant in the first place. So I was correct it is not possible.

0 Kudos
Message 5 of 8
(5,876 Views)

I am bumping this topic. I was wondering namely if the same also counts for the output terminals. Do they also need always be the same?

 

I created a class fooA with a method called fooMethodA this method has as output a default LV object, lvobject. I then created a new class fooB which is implements class fooA, so to say. I override the method fooB but now it has as output a LV object fooC instead of the default LV object.

 

Is this also impossible? 

 

Since I really don't understand why this is impossible. Cause the only thing I really do in the override method fooB is calling its parrent and typecasting the output, the default LV object, to a more specific class fooC. So I don't have to do this in my other code.

 

in code;

class fooA {
  private lvobject A;
  lvobject fooMethodA() {
    return A;
  }
}

class fooB implements fooA {
  lvobjectC fooMethodA() {
    A = parent.fooMethodA();
    return cast(A to lvobjectC);
  }
}
-edit- I think I found my answer... http://stackoverflow.com/a/1696349/181245. Well we still don't have a generic T type.
0 Kudos
Message 6 of 8
(5,769 Views)
In a sense we do. It's called the variant and you can wire anything to it.

The more fundamental issue is that you are approaching things in the wrong way if a child class needs to have a different datatype input from its parent. Remember, when working in LV, think in LV; when working in Java, think in Java. Do not try to mix the two.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 8
(5,757 Views)

Short answer: No, you cannot do as the original parent wants in LabVIEW because function overloading is the source of many bugs in text based languages where programmers change the parameters of the parent implementation but forget to change the parameters of the child, so there are arguments against it there, and in a graphical language like LabVIEW, the small usability argument also fails. Just name the two VIs two different things (like MyFunction_String.vi and MyFunction_Variant.vi) and be done with it. If you want to give them the same icon, go for it, though I strongly discourage that practice.

 

Longer answer: Go to this page:

LabVIEW Object-Oriented Programming: The Decisions Behind the Design

and then search for the phrase "Can I overload VI names in classes?"

 

As for Wouter's later question... I did not address type covariance or type contravariance in the Decisions white paper, but you appear to have found your answer about generic typing. It's a feature LV does not have yet, but I hope we get someday.

0 Kudos
Message 8 of 8
(5,753 Views)