How can I open a second vi panel from first?

[Microhertz]

What is the best method to open a sub- VI or second VI displaying a background panel.

I have flight instruments on the first panel and want to push a button to switch to an aviation map.  This map should have a button to switch back.

In the future, I want to replace (or add a 3rd panel) the map with Google Earth and GPS.

Have LabVIEW 2009

[camerond]

LabVIEW Help file: "Opening SubVI Front Panels During Execution"

Cameron

[Dennis_Knutson]

Since it appears you are new to LabVIEW, I would suggest that you take some of the free tutorials that can be found on this site. In addition, if you recently purchased LabVIEW, it includes the basic classes on-line for free.

[ogk.nz]

While what the other two are saying is correct, just to solve your problem, simply drop the VI you want to open directly into the current VI and wire it up. Then right click on the second VI and go to SubVI Setup. TO get the front panel of the second VI to appear check the "Open Front Panel when loaded" checkbox.

This may work, but for your application I would recommend a Tab Control, if you hide the tabs and control the visible tab through some button presses or a drop down you should be able to do what you want.

[Microhertz]

After experimenting for a long time I finally got it to work.

It did not work right until I fed back the closing signal of the sub VI to the calling VI resetting the calling button and also automatically resetting the closing button in the Sub VI upon leaving the loop.

Now the map appears and disappears as desired.

However, one problem remains:

The map is always in the background (see picture).  It should be in the foreground when called.

Any ideas???

PS: the VI will be deployed on a 9" tablet computer

[Dennis_Knutson]

How have you set the display properties of the main and subVI? Is the main set to be modal?

Your other comments do not make any sense. It is certainly not required to pass anything from the subVI in order to have s pop-up and a button will automatically reset if you have the correct mechanical action and the subVI reads it correctly.

[camerond]

---

@Microhertz wrote:

After experimenting for a long time I finally got it to work.

---

All right, how did you "get it to work" (your post gives a couple of details, but does not state what overall method you chose for your solution)? Please upload your code (not a picture) so others can be aided by your example, and someone here might be able to help your remaining problem (background/foreground).

Cameron

[Microhertz]

First, I would like to mention that it is difficult to optimize Windows behavior parameters because they behave differently within a LabVIEW session and after closing the orange splash screen.
When you think you got it right, the next day after reboot it's totally different.  That's why you have to close the VI and the orange screen after every parameter change.

Now I have it running with both VIs in the default mode.

First, when I set the main VI to "modal", everything locked up and I had to use task manager to get out.  It happened later with one or two other settings.

I'll attach both of the VI's wiring.   

Last week I had tried the switches with both mechanical actions, static and momentarily - could not get it to work.  Both switches are static now.

I'm happy with the current solution.

Thanks everybody for your input and suggestions

[camerond]

---

@Microhertz wrote:

First, I would like to mention that it is difficult to optimize Windows behavior parameters because they behave differently within a LabVIEW session and after closing the orange splash screen.
When you think you got it right, the next day after reboot it's totally different.  That's why you have to close the VI and the orange screen after every parameter change.

---

What are you talking about??? Are you saying that you have to close down LabVIEW every time you make the slightest change in a program, just to hopefully have it halfway work for you next time?

If this were true, you wouldn't see any of the people on here using LabVIEW on Windows. Nor would you see anybody at all using Windows. With all due respect, the reason you have unpredictable behavior by your program is because you have not written it so as to cause predictable behavior. No, I'm not a Windows fanboy, I know the OS is far from perfect, but using it does not result in random behavior any more than any other OS as long as you play by the rules.

If you would like help with your problem, I'd strongly suggest that you upload your VI (not a small segment of a picture of your block diagram - you can't troubleshoot a picture) for someone to see what's going on. There are many on this forum who are much better than me at quickly analyzing a VI and finding race conditions, uninitialized registers, and many other problems which show up in a dataflow language that don't cause problems in a procedural language, and vice versa. Heck, I may even be able to see something. If you have any really secret proprietary stuff, leave it out. But if you can, upload some kind of working VI (with these pesky subVIs) which illustrates your problem. Otherwise, go with what you have, but don't blame it on Windows and LabVIEW, at least not with this wildly overreaching complaint (unless, of course, you're talking about Windows 2.1).

Cameron

[Dennis_Knutson]

And just from the image, your subVI has a greedy loop. You need a wait inside there. Better to use an event structure.

Making the main modal is an obvious mistake. Do you understand the meaning of a modal window? Making the subVI modal would have worked since you can't do anything with the main until you close the subVI.

Have you taken the tutorials or classes that I mentioned?