Case list too wide for structure

[bracker]

I'm feeding an enum into a case structure.  A couple of the frames handle several cases each and eventually, even more cases will be added.  The problem is that the structure is now getting too small for the longer case lists.  Is there any way to deal with this other than widening the case structure?  It would be nice if a second row of cases dropped down from the case selector.

Another slight annoyance is that if I lump a few cases together into one frame that happen to be in sequence in the enum typedef, then LV creates an ellipsis, and I can't even see the intermediate cases unless I look at the enum typedef or an enum constant.

[Yamaeda]

Sub-vi's are your friend. 🙂

/Y

[DFGray]

Consider replacing your cases with LabVIEW classes.  This will also force you into subVIs, which is a good thing.  Your code complexity will dramatically decrease.

[bracker]

I certainly use plenty of sub-VIs, including inside my case structure.  In fact, that's why the case structure is too small for my list of cases (there's not much code in each case).  I suppose I could put the entire case structure into a sub-VIs, so that it doesn't take up much room on the block diagram--maybe that's what you mean.

I'll have to look into classes one of these days too.

Thanks.

[SteveChandler]

bracker: I'll have to look into classes one of these days too.

Look into it sooner than later. You will not regret it. If you have a list of things that you want to look into one of these days put classes on top of the list or as close to the top as you possibly can.

And guess what. At the basic level classes are much simpler than most people think. Sure there are a bunch of things you get that sound complicated such as inheritance and dynamic dispatch. But you don't need those things right away. Forget they exist for now. At the heart of it you probably already know how to create and work with classes.

If you understand libraries, know what a cluster is and how to bundle and unbundle by name, and if you know what a subvi is, then you already are well on your way to understanding classes. You just need to learn the mechanics (right click and select new/class, right click and select new subvi for data member access, etc)

If I wrote a LVOOP For Dummies book it would consist of a single sentence: A class is a library containing a cluster and some subvis that have permission to access that cluster.

One difference is that the cluster is not a type def .ctl file. It is part of the .lvclass (a fancy .lvlib) file. But that is invisible to you since you edit the cluster just like any other custom control. So it is already easier! You don't need to create a typedef file!

[bracker]

Thanks for the detailed endorsement.  If it's about saving time and simplifying, I'm all for sooner rather than later.