LabVIEW Idea Exchange

I just realized that when creating an interface you cannot create property node folders.

You can see from the pictures below that option is missing from interfaces.

You can also see from that screenshot that it is possible to have property folders in interfaces and they work just fine. You have to edit the xml to do that, but it works. So it is implemented, it is just removed from the IDE.

Now I talked to Darren and he seemed to think the original reasoning was "Well property nodes are for storing things in the class private data and there is no private data with an interface, so you don't need them." I can't really argue with that logic, however, there are times when an existing class uses a property node and you want to create an interface that includes that method. For example you may have multiple instruments that have a VISA ref property. You currently can't create an interface with that "write VISA ref" VI (without editing the xml.) If you create a method with the same name/conn pane and it is not in a property folder, the compiler complains. Now you could just go back and edit the original class and remove the property node and just use a regular method. However then you break every piece of calling code that is using a property node.

Here is a use case, which I think is fairly common - it happens to me a lot:

I inherit some code. It is using some particular instrument (Oscope, DMM doesn't matter) They want to support another similar instrument (maybe newer version of the DMM).

The instrument code is wrapped in a class. Great. As a first step, I can refactor. I can create an interface that has all the same methods and make the code rely on the interface. If it is a class wrapped in a DQMH module, all I have to do is replace the object in the Shift register with the interface and somewhere set the concrete class in the initialize. It all works exactly the same as before, but now I have an interface.

Then I create another class that implements that interface and add some logic to pick which one - some kind of factory. Done. I've made very minimal changes to the existing code and it now supports a different instrument. This is the holy grail of OOP. I create a new class and just inject it and everything works.

Not so fast. NI has decided I shouldn't be able to do this if the class uses a property node (oh no!) why? I should be able to have 2 classes that both have the same property. Sure the data's not getting stored in the interface, but what does that matter?

It does matter to the compiler. If I want to do what I proposed above and the original developer used property nodes anywhere this doesn't work directly. I have to either do some xml hack on the interface or I have to replace all the property nodes in the calling code with subvi calls and then go edit the class and remove the property folders. Why?

It seems like all that is needed is enabling the right click menu, because if you manually edit the xml, it all works. That is already implemented for classes, so I imagine the fix would be rather simple.

It would be nice to get 64bit references. The old 32bit references are build up from two main parts: the descriptor represented on 12bits and the address represented on 20bits. If the application requires more than the available 1048576 references the labview generates an error because the memory is full. The workaround is to close references found in the memory. If an application requires serialization, this rule should be kept in mind. If the application serializes references by an input data, the input data should be limited, which means that really big data can't be handled although the machine have enough memory to handle them. Unfortunately, this feature in the labview has been not changed in the last 30 years although 64bit processor architectures are used world-wide and the 64bit labview plays a bigger role every year.
I think, the main reason is the backward compatibility...but is it possible to provide 64bit references which could be chosen by the developer itself, where the descriptor field will not be changed but additional 32bits are available for addressing? e.g. new option in the labview settings "use 64bit references" or selection (polymorphic) from all native components which could be create a reference. If the feature is supported by (environment) settings, then the compiler uses it generic. If the feature is supported component level, then the references should be checked for conflicts. At the end the architect/developer/application is no more limited inside in the labview because the available 4503599627370496 addresses are more than enough for a long time again.