From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Mads

Drop the pane hierarchy

Status: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.

When you create multiple "panes" in a front panel - e.g with the use of splitter bars or tab controls - LabVIEW has a "smart" function that sorts all the controls and indicators by pane when it needs to display a list of the available controls and indicators. The problem with this however is that even with a very low and probable number of panes the resulting hierarchy becomes unwieldingly large.

 

Figuring out which pane you are looking for becomes a pain. If you have not named all your splitter bars e.g. (which most likely is the norm) it gets really frustrating to search through the contextual menu.

 

So - my suggestion is that the hierarchy is either dropped or that you can choose to do so in the LabVIEW options (after all, even with 50 controls it would be quicker to scroll through a flat list than to hunt through the hierarchy first)..or that it is only used after a certain threshold for the number of controls.

 

A third option might be to visualize in the menu itself where on the front panel the different panes are located...that way you will know which is which event though you have not named each splitter etc...

 

hierarchy problem.gif

4 Comments
Andrey_Dmitriev
Active Participant

Agree. But Splitters and Panes (especially Panes) should be also present in the list (Its can be plain list). For example, I using Pane->Origin property pretty often for setting origins to zeroes (for preventing troubles if origing was occasionly changed during development). Splitter->Position property also used by me. So, in general all objects on FP should be in the list, but plain list would be better here. Tree represetation also not bad, but it should be organized in other form (like tree control), so all childs can be exapanded, and every control can be found easily - in addition this will give us good usable overview about splitters/panes/controls hierarchy.

 

Intaris
Proven Zealot

I think we need both.  Both make sense.  Top-level should have a menu entry for flat control list.... Just my 2c

Mads
Active Participant

I think the main help that the hierarchy might give you is the possibility of disciminating between controls that happen to have the same label. One might think that it would cut down the time it takes to search through the list...but thats definitely not the case.

 

There is also something vaguely illogical about the fact that such additional information is dependent on whether you have divided your front panel into multiple panes or not. But let's say that you wish to help people who have used identical labels and happen to have them on different panes - how do you do it best?

 

I would say that instead of nesting menus, it could be helpful if the controls were all in the same list - but sorted/grouped by pane..(divider with header between each pane) and/or had a pane path behind their names. If the number of controls is very high you could allow 2 levels, with the first one being a flat list of all the panes.

 

Today's solution with a web of sub-panes is just too much.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 5 kudos within 5 years after posting will be automatically declined.