How can I develop a ring-control with sub-menus?

[tst]

And, just because I was bored, here's a very quick example (LV 2009). It's limited to 5 here, but just take that off to create all the methods in the class.

Of course, this doesn't create icons or connector pane elements or error terminals or save the VIs, etc, but those can all be done programmatically.

[m3rl3n]

tst,

I don't think you're mis-understanding at all.

I have three of these to write for now, and my team has already discussed scripting the creation of future wrappers, but we also wanted some time to create from scratch and to do it manually to find best practices before pursuing scripting.

As far as the argument of many VIs (one vi per method) to the one wrapper VI containing each method, I prefer pulling the one VI into a higher level VI and then having a constant control above it that identifies the method being invoked. This allows for more infomation than what can be squeezed onto a icon (without having a zoom or a magnify feature to read the tiny print).

But that is the point. Although that is my preferred programming method, and pulling in the one VI then hunting for the method in the control is a pain without sub-menus, I find that much easier than hunting for the specific method VI each and every time.  Having a way of doing submenues from a enum control or enum constant would be a nice feature.  I'm pretty sure that it is not something that is going to be available right now and I do believe that it would pose some interesting programming challenges for the NI folks, but just my 2 cents worth.

Dan

[DFGray]

If you use a ring instead of an enum, you can do threee things and get what you want.

1. Go ahead and populate the ring with all the available methods.  The user will never see them, but they will be used internally.  This can be done at run-time, since it is a ring.
2. When the user clicks the ring, intercept it with the MouseDown? event and redirect to the menu activation so you can put up a system menu with submenus.  This process is documented in the LabVIEW help.
3. When the menu is selected, programatically select the correct item for the ring and call the right method.

If this outline is not enough, let us know and we can expand it.

[m3rl3n]

DFGray - Yes... that would work. I would lose my self documention feature of using the enum with a case, but I could just add comments. - OOPS - Actually I don't think it will work, as the program would once again have to be running in order for the mouse actions to work...  and this would used while porgramming. 

tst - A followup to my last comment. The nice thing about putting all of the methods in one large wrapper VI is that I can then use functional globals for the object, and the follow-on programmer would not have to worry about those details other than making sure they construct and destruct properly.

Dan

[tst]

Does having a single VI come with the assumption that all these methods have no inputs (or the same inputs)?

If this assumption is correct (which doesn't seem to make much sense) and you're using LV 2010 or later, there is something else you can do which might improve the API - put all the wrapper VIs into a class and expose them through the property node interface. This will allow you to convert a series of calls into a single node and (possibly most important for you) you can use the names of the folders to create a hierarchy of properties, so the end user, at least, can access it exactly like you wanted. The one caveat is that for a property VI you're limited to exactly one input or output.

If the assumption isn't correct, then I don't understand how you this will work - if you have different inputs and outputs for the methods, you're going to need different VIs.

And as for having a selector, if you put all the VIs into a polymorphic VI, you can then display the selector and use that to select the VI and the selector shows the name of the VI. Inside the polymorphic selector you can also create a hierarchy, so that should also help you. The only caveat is that as far as I know, creating poly VIs programmatically is still tricky, but I haven't looked into it in recent versions, so it might have improved.

[m3rl3n]

tst - Interesting... I hadn't thought about a polymorphic VI...  I'll have to investigate that.

As far as inputs and outputs; this is where the class idea helps out along with the use of clusters and typedefs. Even tho there are a lot of methods involved in the Spec An implementation, a lot of the inputs (or outputs) are common such as a double and frequency or power units. Those go into the Spec An cluster.  Any specific inputs to the Display methods go into a sub-cluster called Diplay etc.

It does create a problem in that the programmer must know what inputs and outputs are required with each method invocation, but now I'm wondering...  making that vi polymorphic, would that then show the specific input / outputs needed for that method?  That would resolve a lot.  Thanks for the suggestion I will look into it.  It's been a while since I made a polymorphic and then found that it wasn't too useful for what I was doing, but I think the capabilities of LabVIEW (and my own) have increased since then.

This thread is taking a totally different track now...  Maybe we need to ask the moderator to move it to a different thread?

Dan

[tst]

---

@m3rl3n wrote:

making that vi polymorphic, would that then show the specific input / outputs needed for that method? 

---

Yes, although that's true of all separate VIs. The only caveat for poly VIs is that they all need to have the same connector pane pattern (e.g. 4-2-2-4). Other than that, each VI has its own I/O.

---

This thread is taking a totally different track now...  Maybe we need to ask the moderator to move it to a different thread? 

---

It might not hurt, just in case someone looks for it in the future.

[m3rl3n]

Looks like the polymorphic is the way to go. Using the same connector pane is not a problem, I never vary (well... only in extreme cases) from the 4-2-2-4.  I'm playing with it now. I'll report on any issues, but so far it resolves all of the problems that I had...  the programmer will have a means (still a long list) of selecting the functions they want, but it has the added advantage of then showing the inputs and outputs required for that method!!! I will lose the functionality of the functional global holding the reference to the object, but not a big deal and it will force the programmer to construct and destruct properly. 

Dan

[tst]

---

@m3rl3n wrote:

the programmer will have a means (still a long list) of selecting the functions they want

---

It doesn't have to be a long list. The selector can display the VIs in sub-menus. Look at the DAQmx Read VI for an example. I don't remember the mechanism for this off hand, but it probably appears in the help (although if I had to guess, I would guess you put the names in the polyVI and use colons to create the sub-menus).

Also, you can save yourself some time if you create a template VI which already has the invoke node with the reference and error I/O already set up and connected in the pane and just create a copy of that VI each time. That way you don't have to write special code to handle that part.

[m3rl3n]

Yes, I only got to play with it for a little while yesterday after that last post. I do like how the selection menu on the PolyVI can be catagorized. That will work perfectly and is exactly what I was looking for. Plus as stated, this way when the programmer selects a specific action, they "see" exactly what inputs and outputs are needed for that method.

I don't have a lot of experience scripting, but it now looks like that is the way to go to. Thanks for the example. I did build a template VI and then between the example provided by NI for building a script to build VIs from a template VI and the one that tst wrote, I think I can come up with the script(s) needed to automate the whole process. That way, even a text based programmer could automatically generate the LabVIEW code when the driver is updated.  The only problem is that I haven't figured out how to substitute an invoke node for the template's invoke node....   time for a new thread.