Why can't I create property definition folders on an interface?

[TimBlaisdell]

First of all, don't tell me about how it doesn't make sense because interfaces don't have private data.  Yes, that IS why you can't right-click on an interface and select "VI for data member access" like you can on a class.

HOWEVER, on a class, you can also create properties manually by selecting New -> Property definition folder, and then create the accessors manually by selecting "New -> VI from Dynamic Dispatch Template".  In this way, you can create properties that are not simply the getting and setting of a member of the private data cluster.

WHY can you not do this on an interface?

And here's the kicker:  if you create a normal virtual folder on the interface, save that, and then edit the .lvclass file in a simple text editor, you can change the type of the folder from "Folder" to "Property Definition" and EVERYTHING WORKS!  You can then create the dynamic dispatch accessors and they become overrideable in child classes, and are still properties you can use in property nodes and so on!  

So, there appears to be no reason for this limitation.  The option was just removed from the context menu -- even though all the plumbing is there and everything works.  WHY?

It's just basic object orientation.  Suppose you have am interface like "Vehicle".  You might derive child classes like "Bicycle", "Automobile", "Airplane", etc.  Then, you define some properties on "Vehicle" like "Color", "NumberOfWheels".  "PropulsionType", etc.  These become properties the child classes must override, and each child class might obtain its value from a different source.  There's nothing new or OO-breaking about any of this, and apparently NI has thought about this because IT WORKS if you edit the .lvclass file as described above.

[Jacobson]

It may be a bug, you could create a support request to see if it is.

However, just because you can edit the XML and it works doesn't necessarily mean that NI intended it to work or tested it at all.

[TimBlaisdell]

My question for NI is "why?"

Someone at NI went out of his/her way to remove the "New -> Property definition folder" option from the right-click menu, thus preventing programmers from creating overridable properties.  Yet, under the covers, it DOES all work (I've tested it quite a bit and it works flawlessly).

Why?  Is there some "gotcha" that I haven't encountered?  Maybe there's some edge case where a problem arises.  NI realized that fixing that would be a lot of trouble, so they removed the option altogether.  That makes sense.  I'd just like to know what the reasoning was.

But possibly this is just a bug, as you suggest.  I doubt it because I'm not the first to discover this.  Others have written about it on the forums, and the only answer I've been able to find is along the lines of "properties defined on interfaces don't make sense because interfaces have no private data cluster".  But that's silly.  For example, a Camera class might have property accessors that actually get/set properties on the camera device.  Such a class might not have anything in its private data cluster, so all properties must be created the manual way, but first creating the property definition folder, and then creating each accessor by doing New -> VI from Dynamic Dispatch Template.

Lots of cameras, in fact, from many different vendors, implement the "Basler" interface for getting/setting typical properties, sending common commands, etc.  It seems like it would make sense to make a "Basler camera" interface that defines the properties, and then you could create different child classes that flesh out the features of specific cameras, etc.  It sounds like a perfectly obvious occasion to use OO programming, yet it cannot be done in LabVIEW (unless you edit the XML as I've described).

You might say "why not make 'Basler camera' a base class, rather than an interface?  Then you can define the common properties on the base class."  The reason is that, while many cameras support the Basler interface, the  details of how you communicate with the camera may be different.  It might be via direct serial connection, TCP/IP, or some proprietary method.   It's seems like an obvious occasion to use an interface.

[TimBlaisdell]

I've opened up a service request with NI support.  I'll post their response here.

[Yamaeda]

Nice catch!

It really should be possible! I know not everyone likes them, but i think Properties clean up the code nicely. The only thing i dislike is the full classname incl. the .lvclass in the head taking up much space. 

[UliB]

---

@Yamaeda wrote:

The only thing i dislike is the full classname incl. the .lvclass in the head taking up much space. 

---

Open Class Properties -> Documentation Page and change the Localized Name as you wish.

[TimBlaisdell]

---

@UliB wrote:

---

@Open Class Properties -> Documentation Page and change the Localized Name as you wish.

---

Thanks for this!  I'm going to do this with all my classes from now on!

Just an observation (buggy LabVIEW behavior):

When you change the localized name, LabVIEW does not always (1) change what shows in property nodes (e.g. it continues to show ".lvclass" sometimes, or (2) redraw the property node with the new width based on the shorter name.

To resolve all such problems in a specific VI you're looking at, just drop a property node (Application Control -> Property Node) onto the block diagram, then delete it.  That's all -- just dropping it on there seems to wake up LabVIEW and force it to redraw all the property nodes in the diagram, showing the new name and changing the width of the nodes if necessary.  

[raphschru]

@UliB wrote:
@Open Class Properties -> Documentation Page and change the Localized Name as you wish.

---

There is a tiny drawback to this however: now that you have specified a custom localized name for the class, when you copy the class to make a new one, the copy inherits from the original localized name, which your will have to update manually.

---

@TimBlaisdell wrote:

Just an observation (buggy LabVIEW behavior):

When you change the localized name, LabVIEW does not always (1) change what shows in property nodes (e.g. it continues to show ".lvclass" sometimes, or (2) redraw the property node with the new width based on the shorter name.

To resolve all such problems in a specific VI you're looking at, just drop a property node (Application Control -> Property Node) onto the block diagram, then delete it.  That's all -- just dropping it on there seems to wake up LabVIEW and force it to redraw all the property nodes in the diagram, showing the new name and changing the width of the nodes if necessary.  

---

Sometimes a simple ctrl+click on the run arrow to force recompile the VI can do miracles.

Regards,

Raphaël.

[Yamaeda]

---

@UliB wrote:

---

@Yamaeda wrote:

The only thing i dislike is the full classname incl. the .lvclass in the head taking up much space. 

---

Open Class Properties -> Documentation Page and change the Localized Name as you wish.

---

Thanks! Didn't know that!