Maintain UI state with sub panels

[martin_g]

I've been using sub panels to replace tabbed UI's. In applications with lots of information to display, rather than having a UI with tabs splitting the various views - I have used a sub panel, and various UI's that are loaded when a user chooses.

 

 I have User Events passing UI update messages from various parts of the application, and each of the VI's that run in the subpanel are registered for these events - when they are running.

 

The problem I've found is maintaining state in the UI - if a user switches back and forth between different UI views - opening & closing various VI's in the sub panel - depending when the User Event messages are sent, some UI information may be different to when the user closed the UI.

 

To get around this  I've started sending query messages to the application when each UI starts - but this seems to be getting a bit complicated, and I'm not sure if the benefits of the subpanel outweigh the hassle of getting the latest values each time a subpanel UI starts.

 

Just wondering how others handle maintaining state with subpanels?

 

Thanks, 

 

Martin

 

 

 

 

[drjdpowell]

A simple option is to just keep the UI components running when they aren't in use.  

 

Personally, the publishing-type system I use distinguishes between "Event" and "State" messages, with the latest value of all "State" messages being stored, so that newly registering components can be sent the most recent info without the need to implement "queries" in all the publishers.  It's additional overhead, but it greatly simplifies things.

 

-- James 

[Tim_S]

I agree with drjdpowell. I was worried about (potential) overhead with the VIs that were not displayed when I implemented something similar, so I assigned an index number to each of the VIs, and provided the index and an "Active Index" event that could be registered. The event sends the index number of the VI that is displayed in the subpanel, so it allows VIs to throttle back when they are not visible.

[PaulL]

Martin,

 

I think your goals and approach (subpanels) are exactly right.  I also agree that you should be able to start a view and it should reflect the present state of the system.  All this we do in our system. The views are separate applications from the controllers, and neither requires the other to be running.  When we open a higher-level view, for instance, the subpanels associated with lower-level systems automatically reflect the state information of the low-level systems.  This allows the user to configure the display to use the views appropriate for the task at hand.  (We do not add the strange constraint of requiring all views to run at all times.)  What makes this possible for us is that we use network-published shared variable events, which have the special property that when you subscribe to them they fire an event with a value corresponding to the most recent value.  (At first I thought that was not desirable, but it turns out to be quite handy because it specifically addresses the problem you are wanting to solve.)  Of course, you will have to evaluate whether networked shared variables are appropriate for your application.  (Unfortunately, the shared variable event registration requires the DSC module.  That seems counterproductive to me.)  I'm sure it is possible to build something else that would do the same thing (especially if one could use an off-the-shelf messaging system that has this functionality as an option), but that would seem to be a nontrivial exercise.

 

Paul

[drjdpowell]

I agree with drjdpowell.

Though "leave them all running" is a simple option, I prefer the "have the publishing system remember the latest value" option, similar to Paul's shared variables.

[martin_g]

Thanks Paul & James

I'm not looking for a quick fix, so my preference would be to not leave them running.I'll play around with some of the options you both suggested for storing 'State' messages. The network published shared variable property is very interesting, I'll definately take a look at that, but its probably not appropriate for all applications with needing the DSC toolkit.

[PaulL]

Martin, I'm very interested to hear what you learn in the process.

[martin_g]

So I managed to get back to this issue this week, and implement a solution.

 

I created an 'application state' cluster and used a DVR to access it, I update the DVR in event structures that are registered for the User Event, when it's appropriate to update state. At the moment, it's a pretty basic structure with booleans for 'Test Running' 'Logging' and a few others, but I think it solves my problem.

 

When I launch a new UI in a sub-panel, I read from the DVR the current application state, and then format my UI accordingly. 

 

On this project, I didn't have time to separate 'Event' and 'State' messages, but next project, I think I may combine this method with the DVR. Then it would be clear that all 'State' messages should be updating the DVR, but no 'Event' messages should update it.

[Mike Le]

Sounds interesting; how are you handling access to the DVR? Does a central Controller pass the reference to each subpanel state machine? Is it contained in an LV2? Do all parties have write access?

 

It sounds a bit like a global, which I have a natural aversion to, but I'm not familiar with your architecture, so maybe it's the best fit.

[martin_g]

Hi Mike, 

 

I create the DVR ref at startup, bundle up all my references and pass them throughout the application.

 

Yeah, it is a bit like a global, but I think I need a kind of global functionality. I can potentially change state of the application from many different places, but I want to keep one copy of the overall application state. 

 

Handling write access is a good idea though, At the moment anything anywhere can write to it, I've created accessors to write one element of the application state on each call. I can maybe move those around into private scope of a library. i.e. add the write 'Logging' function as private scope within my 'Logging' library.

[Mike Le]

Have you considered storing all the states in the central Controller GUI?

 

Then when a subpanel is loaded into the main GUI, the state can be passed from the Controller to the newly spawned subpanel state machine.

[martin_g]

Thanks for the suggestion Mike, yes that would be a more elegant solution. Thanks for the tip!

[Mike Le]

It's not an ideal solution, but I've used it in the past. It's substantially simpler using LVOOP. In that case, you can use inheritance and deploy every subpanel with shared methods for starting up and storing their own GUI information.