Need UI suggestions / ideas adding to menus

[CoastalMaineBird]

I've marked TST's answer as the solution, because it solves the stated problem, even though I'll have trouble making it work in my case.

The window needs to have a tab control with 12 pages.

A page will have six "blocks", where a block is one of these tabs with chart/text/slider options.

I wanted to have a typedef that handles a whole page, but I don't think I can do that.

Since one of these "block" tabs needs a channel selector (CONTROL) and a value and a units display (INDICATOR), I can't put them into a cluster.

(I could make all the indicators into controls with local variables, but that's a performance hit I don't want to take.)

I can't put a TAB control inside a cluster anyway (for reasons I don't understand).

And since a TAB control is not a real container (claims in the HELP file notwithstanding), I can't create a TYPEDEF of the tab control with these things inside it.

That means that each one of these 12x6 = 72 blocks is independent - if I want to rearrange things or change the color, I have to do it 72 times.

Yuck.

Still, the question is answered, and I have a new tool in my toolbox.  Thanks to all.

[tst]

It sounds to me like you have too much stuff for a single front panel - if the blocks have shared functionality, turn them into XControls or subpanels and fill them dynamically. This should reduce the amount of code in the system to one of each type of block (whatever that means).

You could also use a subpanel instead of the top-level tab, which is what I usually do, but that might make it harder for you to set things up at exactly the right sizes.

I have no idea how this will affect your original request or the rest of your architecture, though. I don't really understand your description of what the system looks like and how you expect it to function, so giving a more informed suggestion is difficult. If you had a small working demo, it might be easier.

[RavensFan]

---

@CoastalMaineBird wrote:

I've marked TST's answer as the solution, because it solves the stated problem, even though I'll have trouble making it work in my case.

---

Actually, your message #8 is the one still marked as the solution.  You need to unmark that first by going to the Options menu to the upper right of your message.  Then you can go and properly mark tst's message #7 as the solution.

[drjdpowell]

---

@tst wrote:

It sounds to me like you have too much stuff for a single front panel - if the blocks have shared functionality, turn them into XControls or subpanels and fill them dynamically. This should reduce the amount of code in the system to one of each type of block (whatever that means).

---

Just seconding what tst says; there are several possible techniques for dealing with large numbers of controls.  Listboxes and tables, (strict) typedef clusters, popup windows...  With more information about the proposed application, we might be able to make valuable suggestions.

[CoastalMaineBird]

OK, here is more info about what is going on.

Yes, this is a boatload of controls on one window.

This new part is strictly a data-monitoring window.  The main program is controlling an engine, and collecting 300+ channels of data at 10 Hz. I am updating the displays at 2 Hz (every 5th sample).  All the control functions are on another window. There is a TCP data stream coming in from the PXI box, and an event dispatcher which issues an UPDATE DISPLAY event at 2Hz. This event carries the 300+ channels of data.

This new window is going to be on a separate 1920x1080 monitor. All it has to do is display the data. The user needs to be able to choose the channels in whatever order they want, in whatever grouping they want., live, <i>in situ</i>, meaning configuring it ON THIS WINDOW, not in some separate configuration place.  The technician is using the main window to watch how well the engine follows the plan.  The engineer is looking at this new window, more interested in what the data is showing about the test. Maybe they want to see SPEED & TORQUE in a chart, or SPEED  and NOx, and CO2 on sliders or whatever. They have to be able to arrange this stuff on the fly.

Attached is the code for a mock-up I've done, using the suggestion from TST.  Rather than a background boolean, I've used a cluster.

The mockup has obviously not been neatened up: the tabs are still there, things don't line up, it's just to test this code idea that he proposed.

And it works great.

Stage 1 iterates over the major pages, over each block in each page, over each tab page in each block, over each cluster and all contents of that cluster, and accumulates a single array of references to all those controls (there might be 5000+ of them).

Stage 2 registers 2 events and connects to all (ALL) those controls.

Stage 3: at ACTIVATE time, I attach a {Chart | Text | Slider} menu with tags of {0 | 1 | 2 } to the control's existing, or new, shortcut menu.

At SELECTION time, all I get is the reference to the control whose menu was chosen. So I walk up the ownership chain until I find the containing TabControl (it might be a different number of chainlinks above us, depending on whether it was a control in the cluster, or the cluster itself that you clicked on).  Then I use the TAG to set the current page of the Tab control.

There's a JING of the mockup in action: http://screencast.com/t/os3zUcKcWpKk

[drjdpowell]

Here's a screenshot of a past project where I also had to deal with a large number of data items to display for the User (not 300+, but it should work for that many).  In the screenshot it is just running simulated test data, for real applications it gets configured with whatever data is being collected.   The main elements are a single XY graph, and a selection tree of all the data channels.  Clicking on the desired channels in the tree displays them on the graph (the User can also choose which Y-axis to use).  The dashed lines are the same data channels recorded in a previous "run" used for comparison (this software is used in radiochemistry, where comparison to a past "good" production run is very useful).   The tree also displays the current "Live" readings as they come in.  The software is "generic", in the sense that isn't hardcoded for specific data channels but can be reconfigured for different equipment setups and different numbers and types of channels.  If I count right, it has only about 9 actual LabVIEW controls/indicators.  Other functionality is under various menus.  An advantage of small numbers of controls is that one can make the UI fully resizable (in the screenshot it's at minimum size, but the User can hit Full Screen if they want).

Just offered FYI as another possible way of handling large numbers of channels without having to deal with large numbers of Front Panel controls/indicators.

-- James

[CoastalMaineBird]

Thanks, Dr J.

One problem with my scheme so far is that the SELECTORS have to be CONTROLS, but everything else has to be INDICATORS.  That won't work in a cluster and my mockup doesn't deal with that.

I wonder if I could DRAG a channel name out of a master list, and DROP it on this control or that, to set the channel to be displayed.

Seems intuitive enough, don't know if you can DROP things onto INDICATORS or not.

[tst]

If your mockup is a fair approximation of what you want, then I would definitely say that you should use another method (such as subpanels or XControls), because it looks like you have a lot of duplication.

I don't know if you can drop on indicators (although I'm guessing you can), but it should be very easy to write a little test VI and see if you get the drop events for indicators. Alternatively, you could try other things such as placing the selection options in the context menu for the control or not having them in a cluster.

[CoastalMaineBird]

If your mockup is a fair approximation of what you want, then I would definitely say that you should use another method (such as subpanels or XControls), because it looks like you have a lot of duplication.

--- There's no code duplication, so you must be referring to duplication of controls and indicators.

Alternatively, you could try other things such as placing the selection options in the context menu for the control

--- There's a thought. Don't even need a selector, if we have a channel consist of a cluster of NAME string, VALUE display, and UNITS display, then popping up on the cluster or any of its controls could bring up a menu for choices.

or not having them in a cluster.

--- I put them in a cluster to A... provide the "background" to catch clicks not on a control (you had suggested a boolean), and B) to reduce the number of controls (yes, it's still a boatload).

I've used Subpanels before, but didn't consider them for this, because I'd have to have 12x6 = 72 instances of a single VI, and was thinking the thread manager would puke at that idea.  I've also never been able to figure out when they update (relative to the hosting window).

[tst]

---

@CoastalMaineBird wrote:

I've used Subpanels before, but didn't consider them for this, because I'd have to have 12x6 = 72 instances of a single VI, and was thinking the thread manager would puke at that idea.  I've also never been able to figure out when they update (relative to the hosting window).

---

I would suggest creating a realistic mockup and seeing how it behaves, because a)it might actually behave better and b)it should probably make the code much simpler.
I never used anything close to 72 subpanels (or dynamic copies of a single VI) together, but I would expect they should play reasonably well together.