LVOOP VIServer

[Antoine Chalons]

Hi all,

 

In order to teach myself to use LVOOP -it's about time to start- I've decided to start with a little project that I've had in mind for a long time, I've called it LVOOP VIServer, I hope it doesn't sound too pretentious.

 

The idea is to make a hierarchy of LVOOP classes that matches the LabVIEW Controls class hierachy in order to take advantage of dynamic dispatch.

In a way it is related to this LIE Idea : Improve the "cluster to array" primitive

 

For now I've implemented the parent class "Control" and two child classes "Path Control" and "String Control" and a bunch of VIs to read/write position, size, caption text, caption font and font.

 

 

If anyone is interested in reviewing the code, providing advice or whatever... I've kept it small enough so that if the core concept is not good it can still be changed.

 

The code is hosted on GitHub here, it should be accessible to anyone, let me know if there is any issue of if you would like a zip in this thread.

 

Cheers

Edited January 18, 2013 by Antoine Châlons

[Yair]

After a quick look, here are a couple of comments:

1. I'm not sure whether or not this is a worthwhile project (particularly for learning LVOOP), but it can probably come in handy if you want to generate controls inside picture controls.
2. LV 2010 should allow you to create property folders for accessor VIs, which will allow you to call the VIs using property nodes (easier for the user, and means the need for an icon is considerably lower). I don't remember if in 2010 you can do this automatically from the accessor creation dialog or whether you have to do it manually, but it can probably be automated through VI Server.
3. I don't think you need to write the reference twice in the init VI. Just write it into the Control class and then have the specific class' read VI downcast the reference to the correct class.
4. You could probably gather the init VIs into a polyVI which will allow the user to create a new "reference" simply by wiring the reference to that VI (although you should check how that behaves first, both with regular references and with strict and unknown references).
   

[Yair]

And a couple more things I didn't notice earlier:

1. Your init VIs are in the control class, which is a no-no. The control class should not be required to know about its child classes. Instead, have a separate init VI for each class inside that class (you will still need to give it a full name to avoid having LV think it's a DD VI). You can collect these into the PolyVI I mentioned earlier.
2. The Control class then has a set ctl ref VI, which is the VI these init VIs call to put the ref into the object data. If you want to protect it, you can make it protected scope, which should still allow the children to call it.
3. You might wish to follow the VI Server hierarchy exactly. The Ring class actually inherits from Control>>Numeric>>Named Numeric.
4. Likewise, implementing the actual classes yourself would mean you didn't have to rely on the LV UI, but that is really a lot of work and is probably not worth it.
   

And regarding that last part, I only now really looked at what you're doing, and I'm not sure I understand the point. Sure, this could work for the idea in the IE, but is there anything else it's good for? In many ways, the VI server API already works like DD VIs do, so there shouldn't be a need to wrap it.

[Antoine Chalons]

Thanks a lot for taking the time to have a look and comment.

 

I have no illusions about how usefull this code can be, as I said I wanted something simple to start teaching myself that's why your comments are very appriciated.

I wont have much time this week to work on this subject but I'll definitely go back to my code with your comments in mind and probably come back here with questions.

 

Cheers