Transfer must overrides?

[Intaris]

Interesting new option for LVOOP.

But what does it mean?  Does it mean that a child class can choose to make a property which is Dynamic dispatch int he parent into a non-dynamic dispatch and vise versa?

I don't seem to be able to find much information on the subject at all......

Sorry if I'm posting stoopid Qs.

-Edit- Yup, Stoopid Qs.  I found it in the help after all (under "Creating LabVIEW Classes").

Some child classes might not be able to override the functionality of the member VI. For example, if class Quadrilateral is a child of class Shape, you cannot provide the correct formula for area unless you know the specific kind of quadrilateral. To avoid the creation of an empty implementation of Area VI within class Quadrilateral, you can instruct class Quadrilateral to transfer the override requirement to its own child classes. To do so, right-click the child class and select Properties from the shortcut menu to display the Class Properties dialog box. On the Inheritance page, place a checkmark in the Transfer all override requirements to descendant classes checkbox. LabVIEW then requires child classes of class Quadrilateral, such as Trapezoid and Rectangle, to override Area VI.
 

Have you just gifted us Abstract methods?  This is essentially allowing a class to have a dynamic dispatchVi without an actual implementation, relying instead on a child class to implement the code.  Is that right?  Is so, the Cool factor of LV 2009 just went through the roof.

Shane.

Message Edited by Intaris on 08-03-2009 05:02 AM

Message Edited by Intaris on 08-03-2009 05:02 AM

Message Edited by Intaris on 08-03-2009 05:03 AM

[Intaris]

I know this is a forum and not the Blogosphere, but I'm excited about these new features and since I'm not at NI Week ( 😞 ) I only have the Forum as an information source.....

OK, I think we need a nugget on the new LVOOP capabilities.

I see we have two new very useful options for LVOOP.

1) Child classes MUST Override Dynamic dispatch VIs.  Settable per VI (Via Class properties). Cool.

2) Require overrides to call the parent method.  Settable per VI (Via Class properties.  I often thought this would be a great idea.  Excellent.

We also have the "Community" access scope which I'm sure will prove useful.

I still do not quite "get" the "Transfer Must Overrides" option though.  I see that it refers to the new "Must Override" option, but what exactly is to be transferred?  Does this force propagation of the Must Override all the way down the hierarchy ensuring that not only children but also grandchildren, great grandchildren and so on ALL override this VI?  If so, I feel "Propagate" would be a more intuitive word than "Transfer".

Shane.

Message Edited by Intaris on 08-03-2009 05:22 AM