Revert any changes made on the front panel during runtime?

[1984]

Hello Community,

I'm working on a front panel which changes its look during runtime. The user can resize the FP and according to the new size the controls/indicators change their size, position, color etc. (pls note: the function I realizes is NOT what you can set in the VI properties as "Maintain proportions of window for different monitor resolutions" nor "Scale all objects on front panel as the window resizes")

The problem I'm facing is that once the objects change position/color/size (or whatever) and the VI stops the changes stay on the front panel (currently not running), therefore when I run the VI the next time this current state will be the new initial state.

I could save the the state of the FP objects into a cluster (maybe even to a file) and then reload them once the VI finishes, but this is not a real good solution as this part of the code may not get executed (eg: I have to terminate the VI?).

What I'm really looking for is a way revert all changes initiated during runtime once the VI is stopped, no matter if the VI is stopped by the stop button, by an error, by shutting down labview or the VI just stops normally.

What would be the right was to solve this problem?

thx.

[GerdW]

Hi 1984,

I could save the the state of the FP objects into a cluster (maybe even to a file) and then reload them once the VI finishes

This is the way to go!

but this is not a real good solution as this part of the code may not get executed (eg: I have to terminate the VI?).

Why do you need to terminate your VI?

What I'm really looking for is a way revert all changes initiated during runtime once the VI is stopped, no matter if the VI is stopped by the stop button, by an error, by shutting down labview or the VI just stops normally. What would be the right was to solve this problem?

Your VI should only stop "normally"!

1. Hide the stop button from the user.

2. Handle any errors before quitting your VI.

All problems fixed…

[1984]

Hi,

This is not that much of a problem once the app is built to an exe, but could be a major pain in the back during the development time when you can and should expect sudden stops and crashes. Once I'm changing the FP of the VI and lets say need to stop the execution I'm screwed (the problem could be caused literally by any VIs in my project). Its a bit hard (and simultaneously very easy) to believe that there is not a proper built in mechanism to ignore runtime changes of the FP once the VI stops.

1984

[GerdW]

Hi 1984,

could be a major pain in the back during the development time when you can and should expect sudden stops and crashes. Once I'm changing the FP of the VI and lets say need to stop the execution I'm screwed

When you need to stop break your VI that often even in the development environment then you should implement an additional button on your FP to save the current configuration before exiting the VI…

(I usually don't "can and should expect" to stop break a VI so often…)

[1984]

Hi,

Yeah, I was thinking about this and I probably will have to go with this if there is no other - more straightforward - solution exists. Its just that right away I can list couple points where using this approach will cause trouble. 

I guess it depends on the person, I stop break abort the execution of my VIs fairly often at the early stage of the development.

1984

[Yamaeda]

If you move around and resize objects in your VI it should be fairly straight forward to get all Control refs, get their position and size, and load/save them to file. You could have 1 Default/init file and a runtime file.

/Y

[1984]

The option for saving and loading was understood at the beginning (see the original post). Its possible but certainly not ideal. I was looking for a better option, but it seems no better option exists.

[Ben]

---

@1984 wrote:

The option for saving and loading was understood at the beginning (see the original post). Its possible but certainly not ideal. I was looking for a better option, but it seems no better option exists.

---

Not ready built out of the box.

Now if I really wanted it...

Spoiler

An associate wanted to be able to get at any control in any VI in an application using an enum to choose any control from a drop-down list and get a reference to the control down in the bowels of an application. I advised against it but he thought it would be a fun challenge. Since I am of the ilk that will give people enough rope to hang themselves I suggested he develop a variation on an error cluster that was actually an XControl. Since the XControl runs when is other modes than just "run Mode" it can have logic that runs when the VI changes states from running to not and vise versa. So his XControl had logic that would run when a VI was loaded or changed states to go through every loaded VI, grab a references to each control and update an enum with strings that ID'd each control. Since the XControl would run when the main VI was not running, the enum could be edited.

The code worked but I never liked because it opened the door to chaos and besides the control refs where always generic and I would have to cast the control ref to the strict class to be able access the special options of controls that were not available for generic controls. The other thing I did not like is the XControl would save all of that info in it's private data every time the VI was run and stopped. So SVN was constantly being triggered since a VI changed. I pay attention to the "dirty dot". If I see that, I want to know what changed and save it.

Spoiler

You could do a similar thing and create an XControl that went through the FP it was owned by and save the location, and dimensions of every control and cache those in the internal data of the XControl.

But that is a lot of work and besides you will be questioning why the state of the VI needs changed when you did not think you changed anything.

Ben

[1984]

I have found a VI called Traverse for GObjects.vi (unsure if it comes with the default LV install of if its a toolkit), which can extract all the references from the front panel, decorators included.

Once all the refs are given - like you said - all the refs need to be casted to more specific cast to get all the type spec properties, then these have to be stored. Its doable, but rather painful.

[paul_cardinale]

---

@1984 wrote:

Hi,

This is not that much of a problem once the app is built to an exe, but could be a major pain in the back during the development time when you can and should expect sudden stops and crashes. Once I'm changing the FP of the VI and lets say need to stop the execution I'm screwed (the problem could be caused literally by any VIs in my project). Its a bit hard (and simultaneously very easy) to believe that there is not a proper built in mechanism to ignore runtime changes of the FP once the VI stops.

1984

---

I have this issue all the time.  I don't know a nice solution.  I just don't save after running.  If I need to make edits after a run, I move something on the front panel (giving the asterisk) then I revert.