Dot Notation for Auto Submenus for Easier Navigation of Long Lists

[NickNZ]

Navigating long lists in LabVIEW can get painful, e.g. for producer consumer design patterns and message handlers. 

This idea is to add submenu parsing for dot notation items.

Now your case structure can do this:

I don't think it will effect ranges in the case selector as it requires two dots... e.g. "Init.Step1".."Init.Step4"

Credit: This thread for inspiration: https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Case-structure-easier-selection-for-structures-with-a...

Suggestions required on how to handle a list in this situation where its a lot of numbered messages. 

Also I just learned from a colleague that by grouping controls carefully (& some caveats) with the dot notation on FPGA it allows for a submenu. (And clusters on a FPGA can take up a lot of gates).  So LabVIEW already has some code for this feature. Can it be leveraged? See below:

https://forums.ni.com/t5/LabVIEW/Group-FPGA-Controls-With-Dot-Naming/td-p/2767678?profile.language=e...

This post generated this idea which is the same problem in the FPGA space... grouping long lists to make them easier to use.

https://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Better-FPGA-FP-Control-Selection/idi-p/3074718

[AristosQueue (NI)]

Seems useful to me in most cases, but there's one gotcha for using a period or any common character as a meaningful delimiter within an enum string... I can easily imagine an enum that represents specific values (because I've written one!) where enum values include "3.141" and "2.718" as representation of specific test values. Cluster names are not as fundamental to code the way enums are. We would likely need to pick a character combination as the separator that is unlikely to "occur in nature", so to speak, like "@@@" or something weird, which might make the enums themselves hard to read.

I wonder if we could somehow annotate the enum .ctl file with a menuing setup? In other words, not provide this functionality for non-typedef enums, but for those that are typedef'd, have instructions in the .ctl file for how to group a hierarchy of the values... that would eliminate the need to have any delimiter within the enum string itself. ... maybe it is as simple as using a dialog to arrange the enum items into hierarchy (similar to the .rtm file menu editor).

It's a tricky situation when you start welding interface onto implementation, but I think there's utility down this line of brainstorming. I'll give it my personal kudos, and we'll see what R&D thinks.

[NickNZ]

For AQ's enum of numeric constants, the idea was that you would not enable this option under appearance tab of the enum or ring control properties - see first screenshot - which would be the default to maintain backwards compatibility. Then you would get the current single level menu list of all your magic numbers. Finding a solution to the long lists problem is unlikely to be a generic solution for all use cases. A solution that is useful to 80% of use cases 80% of the time is.

Interestingly I used the run time menu dialog to create the menu for the screenshots above as it seemed the easiest and obvious way. It was not a nice user experience. (Probably because I don't use it often and I had fun getting the indenting right, and adding a new item in the right position and it sorted correctly).

I would find it acceptable to be part of a typedef control. I see the Runtime menu option is currently disabled in the menu for a typedef for the enum. However may take a while to sort for a large menu. So it could take while to setup vs adding dots to your enum strings.

[AristosQueue (NI)]

NickNZ: We can't use configuration options to control case structures and bd constants, and I don't think users would be happy if this had to be enabled on every individual thing that used the enums. It has to be something that propagates with the type. That works if it is a typedef and we can reference back to the typedef file.

I was reminded that tying to the typedef means that if we disconnect typedefs during AppBuild, then the UI that uses the enum ring would break. My response is "People use enum rings in end user UIs?!" Yes, I know people do, but that's an absolute no-no for me (because enums cannot localize and my code ships out all over the world), so I forget to take it into account sometimes.

[NickNZ]

AQ: Agree enabling the menu on every case structure would be annoying, even if there is only one consumer case structure, there are likely to be many enum constants around the BD.

Propagation with a typedef then it can break when built into an EXE ("Why doesn't my nice submenu not work when I build it into a EXE?") is probably a deal breaker - unless there is a hook that the typdef can stay to the EXE builder - don't disconnect me! Not sure if this leads to other issues - I assumed it was just to save space on the build? I have not really learnt much about the pros and cons to checking or not that disconnect typedefs in the EXE builder. 

Question 1: Is the functionality useful? Please think about other long list issues.

Question 2: How can this functionality be realistically implemented?

Question 3: Is it just a programmer tool/helper or also something for the UI for the users as well?

Q1: Lets check the Kudo count. 

Q2: I am not sure a new control that is a merge of the Enum and Tree control is a good answer. 

(I would request the mixed type list box NXG has over this idea).

Perhaps on invocation, when you click on the enum, ring or case structure can you invoke a submenu parse with e.g. ALT key? But then discoverability takes a hit and you can't choose how to sort the list, and OS issues with key mappings. 

Or do we do the RTM menu thing and load it onto the case structures that we want to use it on, assuming most people only have one consumer case structure for a large enum. You wouldn't bother with a enum with less than 10 items. Not very intuitive and probably a too much work for the devs to get off the ground. 

Q3:Its probably not a great UI if you prompt the user with an large enum to pick from. We put up with it currently as programmers where we have many states and messages to handle in the back end. Therefore is it an IDE option? But then get my "Enum in my exe doesn't have submenus or on my colleagues PC!"

I hope this discussion leads to some smart ideas that can build on this and overcome AQ's roadblock. ⚽

[wiebe@CARYA]

If this would be somehow possible to do with an enum, it would be helpful to add that enum to a menu.

Menus are plain hell. I've code that parses a string with hierarchy information, without sub VIs like that it's really impractical to do anything with (dynamic) menus.

An enum that has a hierarchy would solve this:

Of course, now I have this idea I can make a.vim that does this myself...

[NickNZ]

Hi Wiebe - agree that would be useful as well to create menus.

I like the idea of ._ putting in a separator as that also improves navigation of menus. However would have to arrange by index of enum in that case rather than sort alphabetically as it won't be obvious where to put the separator. i.e. programmer has to keep enum sorted. I think LabVIEW has got better over the years coping with enum items being inserted and removed in a typdef during development. 

The custom run time menu must survive the build process. 

I figure it should be possible to create a X Control that when you right click it creates the submenu by parsing the dot notation. However this would only solve the runtime side. I think my main use case I am trying to solve is during programming.