Executable FP not responding like debug FP.

[Fred Toewe]

I am trying to hide the FP of my top level application as soon as it is run and am using the suggestion from the knowledge base below. It works in the debug environment, but does not work after the application has been built into an execuable - that is, the top level window stays visible.  Thanks.

==========

Can a LabVIEW VI Run in the Background Without a Front Panel?

Primary Software: LabVIEW Development Systems>>Full Development System
Primary Software Version: 5.0
Primary Software Fixed Version: N/A
Secondary Software: N/A

Problem: I would like my LabVIEW VI to execute "in the background" without displaying a front panel.

Solution: You can run a LabVIEW VI without displaying the front panel. To do this you use VI Server code so that the VI actually calls a reference to itself. Once this reference has been established, you can use a Property Node to set the "Front Panel.Open" property to "FALSE." This will hide the panel.

The attached image is a screen shot of how to do this in LabVIEW.

Related Links:

Attachments:

Report Date: 05/18/2000
Last Updated: 12/09/2004
Document ID: 1XHGS1HE

[tst]

Are you doing it exactly as shown in the picture or are you feeding the path yourself?

When building an application into an EXE the executable file itself acts like a directory, so the path to the VI is now c:\...\app.exe\toplevel.vi.

If this didn't help you, I suggest you post the relevant piece of code, or at least an image of it (no BMPs, please).

[Fred Toewe]

Yes, I am doing it exactly like the KB article.  I would have included a image of the block diagram if this tool would have let me.  Fred

[Fred Toewe]

Here's that image.  Just found how to attach it.

[tbob]

I don't think the Open VI Reference will work on an exe.  Try running the exe by calling it using SystemExec vi (found in Communications palette), and set the Run Minimized input to True.

[Fred Toewe]

Wouldn't that just change the problem of who's the top level VI?  The the VI calling my former top level VI would be the new top level and have the same problem.  Fred

[Fred Toewe]

There is another clue.  Most (perhaps all - haven't tried but a few) of the window appearance characteristics that you are supposed to be able to control via VI Properties have any effect.  They work as you would expect in the debug environment, but not in the executible.  They also work correctly for the other visible FP (GUI_Execute.vi in MyProblem.gif) in both the debug and executable versions.  So, I was wondering if perhaps I am poking a hole in the LB runtime engine and partially crippling it? Fred

[tst]

I have a guess as to what your problem might be.

As far as I know (I'm almost positive), the RTE needs an open FP to hold itself open, which is why I'm guessing it won't let you close the front panel of the top level VI, at least as long as there are no other FPs open.

Some other options for you:

1. Make the calls dynamic. That way you can run the VI to a finish and close it.
2. Close the toplevel FP after running the GUI VI (use a wait or a semaphore).
3. Make it a splash screen, or a status screen.
4. Try to move the window off the screen, or make it small (look here for tips).

[Fred Toewe]

There is a second open FP in my application.  It is the GUI_Execute.vi just mentioned.  It is not THE top level VI however.

1> Not following your suggestion - I cannot call the top level VI dynamically - can I?  Then it wouldn't be the top level anymore.

2> I dare not close the top level VI until the app finishes entirely.  There are 4 threads running in this sucker and the top level VI does some of the coordination, if only for error processing.

3> Not following your suggestion - where does my top level VI go then?

4> Too Rinky Dink and not a real solution.  I am trying to make something the looks and works like a normal Windows application. 

Thanks for trying,

Fred

[tst]

There is a second open FP in my application.  It is the GUI_Execute.vi just mentioned.  It is not THE top level VI however.

It only opens after you try to close the FP of the top level VI. You need to reverse the order (see #2). If you want to make sure it stays in memory, open a reference to it from one of the subVIs.

1> Not following your suggestion - I cannot call the top level VI dynamically - can I?  Then it wouldn't be the top level anymore.

Make the calls to the other VIs dynamic, not the top level one. Many people do that and you can use the top level VI only as a splash screen that will call the other VIs and shut down itself. Search this site for info about a "loader VI". This will obviously hurt some of your error handling.

2> I dare not close the top level VI until the app finishes entirely. 

I said close the top level FP, not VI, which you're doing anyway. I just said reverse the order. You can also go for the other option of closing the VI.

3> Not following your suggestion - where does my top level VI go then?

Either close it, or make it a status window of some sort.

4> Too Rinky Dink and not a real solution.  I am trying to make something the looks and works like a normal Windows application. 

Well, things don't always work out the way we want them to. LV isn't windows specific and as such creates some trouble when attempting to make "standard windows apps". Although I still think you shouldn't have a problem with this.

In any case, you may be able to set the property Front Panel Window>>State to Hidden, although I think it would do the same thing.