Flaky Embedded Panels

[Sergey L]

Hi all,

I have a project in which I have a main VI with 3 subpanels; at different times during program execution, different VIs are embedded in these subpanels. What I see is that occasionally the whole user interface get unresponsive (all controls in all subpanels and the main panel), even though all indicators continue updating. The same problem appears when the program is built into an executable.

This problem occures in both LV7.1 and LV8. In LV8, I found a strange way to recover from this situation without killing LV: right-clicking on any icon in the PROJECT window, so that the drop-down menu comes up, makes the stuck front panel responsive again (you don't have to select anything in this menu - just let it appear briefly). This applies even to right-clicking on icons of support files. Also any project window menu selection that brings up another window (e.g. About) revives the stuck VI. Not a viable solution for a built application though...

Any word of advice?

TIA, -- Sergey.

[Jeffrey Habets]

Any chance you are using the DeferPanelUpdates propertie in your application?

I've noticed this behaviour too (in LV8) but haven't really investigated it. *I think* it has to do with nesting constructs like:

MainVI->DeferPanelUpdates := true   MainVI->DeferPanelUpdates := true   MainVI->DeferPanelUpdates := falseMainVI->DeferPanelUpdates := false

At least.. Preventing this does the trick for me..

[PJM_labview]

Hi all,

I have a project in which I have a main VI with 3 subpanels; at different times during program execution, different VIs are embedded in these subpanels. What I see is that occasionally the whole user interface get unresponsive (all controls in all subpanels and the main panel), even though all indicators continue updating. The same problem appears when the program is built into an executable.

This problem occures in both LV7.1 and LV8. In LV8, I found a strange way to recover from this situation without killing LV: right-clicking on any icon in the PROJECT window, so that the drop-down menu comes up, makes the stuck front panel responsive again (you don't have to select anything in this menu - just let it appear briefly). This applies even to right-clicking on icons of support files. Also any project window menu selection that brings up another window (e.g. About) revives the stuck VI. Not a viable solution for a built application though...

Any word of advice?

TIA, -- Sergey.

I noticed this "unwanted behavior" since the first time the subpanel where introduced in LV 7.0. I spend considerable amount of time trying to figure out what was causing it, but I was never able to exactly identify the problem. As best as I can remember (I have not used subpanel that extensively since then) this has to do with how "fast" you swap your subpanel and how you are doing it (meaning how you used the subpanel properties and in which order). One thing I seem to remember is that if you stop the SubVIs when they are not in the subpanel it seem to help. I never tried the defer panel update, but this might actually help now that I think about it.

Sorry if this is not that helpfull, but this is all I can remember.

PJM

[Sergey L]

...One thing I seem to remember is that if you stop the SubVIs when they are not in the subpanel it seem to help...

Guys, thanks for your replies! No, I don't use 'DeferPanelUpdates'. Actually it seems to start working now, after I made a change which is in line with PJM's comment: earlier I used to embed a panel of a subVI and then call it (statically). When the call finished (i.e. the subVI stopped), I removed its panel and embedded the panel of the next subVI. It worked most of the time, but after 20-30 calls it failed with the front panel of the main VI (and everything embedded) becoming non-responsive.

What I did now is calling my subVI first, and then, within the subVI, embed its panel into the subpanel container of its caller. When the subVI is ready to finish, it removes its panel from the caller's container and then finishes. This seems to work so far, at least it still works after I cycled through various panels more than 50 times!

[Michael Aivaliotis]

Guys, thanks for your replies! No, I don't use 'DeferPanelUpdates'. Actually it seems to start working now, after I made a change which is in line with PJM's comment: earlier I used to embed a panel of a subVI and then call it (statically). When the call finished (i.e. the subVI stopped), I removed its panel and embedded the panel of the next subVI. It worked most of the time, but after 20-30 calls it failed with the front panel of the main VI (and everything embedded) becoming non-responsive.

What I did now is calling my subVI first, and then, within the subVI, embed its panel into the subpanel container of its caller. When the subVI is ready to finish, it removes its panel from the caller's container and then finishes. This seems to work so far, at least it still works after I cycled through various panels more than 50 times!

That this is the solution. Even if you look into the NI embedded panels examples that ship with LV. They always start the subpaneled VI's first before they embed them. This is the key to smooth operation.

[Sergey L]

Since my last posting, two things happened: the problem came back and I found the culprit. It was a combination of my sloppy programming and LabVIEW inability to handle it. What actually happened was that in some subVIs I had an event structure within a While loop; after the event structure (still within the loop) I had an IF statement and when this IF was wired for TRUE, I set up a signalling property of one of the controls which had a corresponding event.

Unfortunately, when exiting the while loop, I also executed the IF, therefore setting up an event, even as the while loop and the subVI itself were exiting. In most situations, nothing bad happened, but occasionally the calling VI (in which the subVI was embedded into a panel) froze. Now I make sure not to trigger any event upon exit, and everything seems to be stable, so far.

I am not sure that what I described is a LV bug, so I don't think I should report it.

Thanks for your help, guys.

Sergey.