Managing complex GUIs

[Ascen]

I am building an application that needs to use a extensive GUI having ~15 tabs and altogether around 40-60 front page controls

spread across those tabs.

Now, LV GUI is pretty handy for maybe up to 10 controls and couple of tabs, but after that it gets awfully messy, and

putting all the event handling to single event handler loop results in >30 cases.

I can't help but wonder if there is some way of organizing these elements

so that they don't end up being such a clutter that they are at the moment.

[Ton Plomp]

QUOTE(Ascen @ Dec 12 2007, 12:14 PM)

I am building an application that needs to use a extensive GUI having ~15 tabs and altogether around 40-60 front page controls

spread across those tabs.

Now, LV GUI is pretty handy for maybe up to 10 controls and couple of tabs, but after that it gets awfully messy, and

putting all the event handling to single event handler loop results in >30 cases.

I can't help but wonder if there is some way of organizing these elements

so that they don't end up being such a clutter that they are at the moment.

Use one event structure for every tab-page might be the option, and use a messaging technique to start and stop actions.

Another question is to asky why do you have 15 pages? Do they all need to be accesible instantly? Are they all setting stuff and displaying stuff?

Tonr

[Ascen]

QUOTE(tcplomp @ Dec 12 2007, 01:27 PM)

Use one event structure for every tab-page might be the option, and use a messaging technique to start and stop actions.

Another question is to asky why do you have 15 pages? Do they all need to be accesible instantly? Are they all setting stuff and displaying stuff?

Tonr

One event structure / tab page would be an option, but that would lead to having to manage several event loops in case

of a change. A bigger issue is that I havent figured out how to group these objects logically - I may have 20 objects named "Input1"

in the event selection list, since the control names are cut off at some length (or at some special characters? I use TABNAME:CONTROLNAME naming convention)

I am building a training simulator for a panel-controlled logic controller, and I have N pages because that is what the controller has.

And yes, they need to be accessible at least somewhat instantly - separate popup windows from subVIs are not an option.

There are some pages that are there just for navigating the GUI (maybe 1-3), but most pages display data.

[LAVA 1.0 Content]

Just a thought...

If each tab was a sub-panel you could use User evnts and Action Engines to coordinates changes and the top level VI reduces to a sub-panel loader.

Done thinking!

Ben

[crelf]

QUOTE(Ascen @ Dec 12 2007, 09:14 PM)

I am building an application that needs to use a extensive GUI having ~15 tabs...

15 tab controls, or a tab control with 15 pages?QUOTE(tcplomp @ Dec 12 2007, 09:27 PM)

Use one event structure for every tab-page might be the option, and use a messaging technique to start and stop actions.

I'd use one event structure - why do you need one for each page? I'm not a fan of multiple event structures - sure, it's a powerful technique, but it's easy to end up with issues that are difficult to track.

[Guillaume Lessard]

QUOTE(crelf @ Dec 12 2007, 09:42 AM)

I'm not a fan of multiple event structures - sure, it's a powerful technique, but it's easy to end up with issues that are difficult to track.

I completely agree with this. I wrote a GUI with multiple event loops and it rapidly turned into a nightmare.

I converted it to a single event loop with message passing. Each tab (which represent modes of operation in my case) has its own message processor, and it just ignores any messages that don't make sense. The code is much more understandable now...

[JDave]

QUOTE(neB @ Dec 12 2007, 06:19 AM)

Just a thought...

If each tab was a sub-panel you could use User evnts and Action Engines to coordinates changes and the top level VI reduces to a sub-panel loader.

Done thinking!

Ben

I don't even have to think. A simple "I concur" suffices.

Except I started thinking... You only need one subpanel, and wouldn't need any 'tabs'. The different VIs that are loaded into the subpanel serve as the different tab views.

[silmaril]

QUOTE(Ascen @ Dec 12 2007, 03:11 PM)

One event structure / tab page would be an option, but that would lead to having to manage several event loops in case

of a change.

I agree with crelf that several event loops may end in some very hard debugging sessions

I also don't see why it should be a problem to have a large number of event cases in one event structure.

QUOTE(Ascen @ Dec 12 2007, 03:11 PM)

A bigger issue is that I havent figured out how to group these objects logically - I may have 20 objects named "Input1"

in the event selection list, since the control names are cut off at some length (or at some special characters? I use TABNAME:CONTROLNAME naming convention)

Such a naming convention is certainly a very good idea. All you need now is a good list of short tab-names and control names.

You should keep in mind that the label (=logical name) and caption (=displayed name) of a control don't need to be the same.

In your case I would strongly suggest to use some nice short labels and display only the captions.

A not-so-well-known fact is that you can do the same for the tab control pages: Right-click on a page and select "Advanced >> Make Page Caption Match Label". You have to do this for every page separately.

QUOTE(Ascen @ Dec 12 2007, 03:11 PM)

I am building a training simulator for a panel-controlled logic controller, and I have N pages because that is what the controller has.

And yes, they need to be accessible at least somewhat instantly - separate popup windows from subVIs are not an option.

Are the pages of your logic controller really different from each other?

If they are quite similar, maybe it would be a better approach to have one control (e.g. an enum) to select the page an then re-use the same controls for every controller page.

If there are some small differences you could manage them by hiding the controls you don't need.

This would transfer some complexity from the UI to your data management code. But since you need to manage all that data anyway, I assume that you would end up with less complex code over all.

QUOTE(Ascen @ Dec 12 2007, 03:11 PM)

There are some pages that are there just for navigating the GUI (maybe 1-3), but most pages display data.

If it's only display, then my suggestions above should be even easier to handle.

Sub panels have already been mentioned as an alternative. This sounds like a very good idea to me, too. You could have separate display VIs running for all your controller pages, but only one of them shows it's front panel inside your (one) sub panel.

And I think you don't need to worry about display performance here. Maybe you loose a bit of time changing the displayed panel, but if this is implemented properly, it will still be much faster than the average human being's perception

[Norm Kirchner]

Look at the LV options dialog.

This is much better than using tabs.

Give a list to the left, and use a sub-panel to the right. That's what NI does and it looks pretty handy. Flexible too when it comes to adding / removing pages

~,~

ps, sorry if someone already said this, don't have time to read through the thread.

[Gustavo Fernandes]

QUOTE(Norm Kirchner @ Dec 14 2007, 05:26 PM)

Look at the LV options dialog.

This is much better than using tabs.

Give a list to the left, and use a sub-panel to the right. That's what NI does and it looks pretty handy. Flexible too when it comes to adding / removing pages

~,~

ps, sorry if someone already said this, don't have time to read through the thread.

Please, can you point me to a code example. TiA.