Can set FP.TitleBarVis to False

[lharley]

I am trying to make a Splash Screen. I have looked at a number of example VIs and have tried to adapt what I have found. I have a Splash.vi as a separate VI and I'm calling it from a main VI that is initializing parameters and opening processes for a large application. No matter what I set, I can't create a floating Front Panel with no title bar. The Menu Bar and the ToolBar are also always visible.  I have set the VI properties for the Splash screen as well, but calling the Splash.vi with FP.Open seems to override what I've set. I have researched the issue and found a reference that says I need to split setting FP.TitleBarVis from the the other properties. But this does not work either.  I have been programming with LabView about 6 months, so I'm relatively new, but I feel pretty comfortable with references and property nodes. I am attaching a screen capture of part of the Block Diagram with my FP.Open routine. Can anyone help?

[JÞB]

Did you look for a "Splash in Main" or "The Little Things".  Some of the community content is still being migrated but Google should help.

Mark and Fab are both better at that stuff than I am

On the other hand.  did you think about naming the splash screen "About.vi?"

[JÞB]

And

Champion Tip

The Problem with Modal Dialog Boxes

Avoiding the “Three-Finger-Salute”

The Problem:

Let’s be honest, we’ve all done it.  You are debugging your project and create a sandbox vi to explore why you are getting that unexpected result run the sandbox and “POOF” that modal vi that you had open pops to the front and LabVIEW becomes unresponsive.  We need to press Ctrl+Alt+Delete, bring up the Windows Task Manager, and kill LabVIEW (losing all our changes in the process!)

The Reason:

Your vi is saved with the “Best Practice” Windows appearance settings.

Figure 1 Modal Appearance Settings

Every Windows application developer will tell you that the desired operation of your modal dialog is that it should not be closable by the red x and block all access to the rest of your application when it is active.  You DID have a reason to create that Dialog Pane in the first place!  Your code is in an unexpected state and needs a human to provide an acknowledgement or make a decision.

Amplifying the problem:

• Legacy Versions of TestStand can load modal dialogs into memory and hide the pane hanging LabVIEW and TestStand.
• Unit Tests for dialog boxes or Modal GUIs cannot be written effectively since you cannot interact with the test framework while the dialog is open (Under Test.)

The Misconception:

This is just one of many examples of LabVIEW “Best Practices” that “Everyone knows about” but, has been obsoleted by improvements made to the LabVIEW development environment.  In this case the practice should have changed between 5.1 and 6.i when VI Server was first made available.   The misconception being that the VI must be saved knowing its Windows Appearance settings.   Really, only two of those setting can cause us a problem; FP.Behavior and FP.Closable and, they are both writable while running!

Better Practice:

Use property nodes on your dialog vi’s to set the correct windows behavior only while the vi runs!   So we can save the vi with these settings and still get the desired run-time behavior without having the undesired development environment crashes in LabVIEW or TestStand.

The Code Capture is in LabVIEW 2012 the attached vi is saved back to LabVIEW 8.0.  Notice that we have not only solved our primary problem but, we can also change the “Modal” constant to a control with a default value of Modal and attach it to the connector pane as an optional terminal.   Then we have the option to override the default behavior (HINT: make it “Floating”) for unit testing.

[aputman]

Why do you need a floating window and why are you trying to set all of the window properties via property nodes?  These can be set in the VI properties itself. 

The typical use of a splash screen is that it is shown by itself until the main application is fully initialized in the background (not visible).  Only then is the main app made visible and the splash screen is closed.  For this behavior, you only need the default window behavior, not floating. 

Set your splash screen as the default app when starting the EXE and launch the main VI asynchronously within the splash screen.  Pass in a notifier reference to be able to communicate between the splash and main. 

[lharley]

It's not clear why you posted the article on Modal dialog boxes. The information is good information, but I am NOT trying to create a modal dialog box and never stated that I was. So your response did not help me.

[lharley]

Yes, I have looked very carefully at Splash in Main. Based on your suggestion I looked again at Splash in Main to see if I could spot something he is doing that I am not. I couldn't see what I was doing differently. For the most part my code is inspired by the example code in Splash in Main. However, Splash in Main in its current form is a very heavy weighted approach to a simple splash screen. The approach shows how complicated a LabView program can be for a simple task, at least in my opinion. And his approach does not explain why my code, which uses property nodes to set the properties of the VI -- it sets the title bar, menu bar, toolbar to false, just as his does -- doesn't work.

[lharley]

I have done further debugging in an effort to identify why my code doesn't set splash screen to have no title bar (or other window elements, like a toolbar and menubar). One suggestion made was that I use the VI Properties for the VI itself to turn off the title bar, menubar, toolbar. I have done that, but FP.Open and FP.Run  don't work as expected. It's as if the splash window opens, but doesn't actually run. If I manually run the Splash.vi from its own run button, the titlebar, menubar, etc are removed. I do not get any error messages, so the code seems to execute properly.

I created a simplified test file with a simple while loop to open the Splash.vi. This test file works perfectly. However, when I enclose the code inside queue message handling routines -- same exact FP.Open and FP.RunVI routines -- the Splash.vi does not work as expected. However, it works with the Light Bulb trace is on.

A really interesting curiosity is that if I run the code with the Light Bulb trace code ON -- inside the complex message handling routines -- then the code works correctly. That is, the Splash.vi opens, runs, and the window chrome elements are all removed. When I turn the Light Bulb OFF, the chrome is is back on the Splash.vi window. Can anyone explain why this would happen?  What is different about LabView when the Light Bulb trace is on?

I would upload an example of my code for inspection, but the security rules of my company prevent me from uploading anything to a public forum. 

[RavensFan]

When things behave differently based on whether highlight execution is turned on or not, that is usually the indication of a race condition.  Is there anything in your code that requires a certain order of execution, but may not be happening because the data dependency is not set up?  Perhaps a reference is disposed of before it is needed?

Unfortunately, it is very difficult to debug a paragraph.  So it is a shame you can't upload even a simple example of your VI so we can test what is going on and see why it is not working.  You were able to upload a screenshot.  (It would help if you ran a block diagram cleanup and straightened up the wires.)  But it doesn't show enough code to be able to try to debug a picture.

I do see in your screen shot a number of constants have coercion dots where they go into property nodes.  The ones that particularly concern me are the enums Floating and Standard.  They are typedef, which is good, but for some reason, the typedef must not be matching what the property node expects.  Delete them, right click on the property node and pick create Constant.  Pick the choice out of the enum.

[aputman]

I uploaded an example splash screen in this thread yesterday for another user.  

[lharley]

Your thoughtful discussion got me thinking about how to isolate and debug problems. I eventually found a number of issues with my code, not directly in the FP.Open routine but generally. The primary problem was the one you suggested. In one routine I was disposing of the Queue reference and then trying to enqueue and dequeue to that reference. I also cleaned up all but a few enum conversion dots.

Once I was satisfied that the general Event and Queue loop framework was sound, I began trying various options for showing and manipulating the Front Panel of my splash screen (similar to Splash in Main). I found that the property settings for the Splash.vi (File > VI Properties) had to be set just right or one property conflicted with the ones I was trying to manipulate in my code. For instance, if you set the bounds of the Front Panel in code, LabView seems to ignore the monitor settings for Monitor 0 or Monitor 1 in favor of the bounds. [Makes sense, right?] In the end I adopted an approach (someone else suggested) where I set the Splash.vi properties in File > VI Properties for how I wanted the window and front panel to look, and then simply called the Splash.vi as a reference in my code and opened it with FP.Open. I'm attaching a snippet screen capture of the FP.Open routine that worked for me in the end. 

I appreciate all the suggestions and help, but I have to say that debugging the problem was not easy. In programming for HTM/CSS/JavaScript, the built-in debugging tools for browsers allows you to see the entire tree of commands and settings. You can see which commands and settings are conflicted with each other and which are overwritten or nullified and at which level. With LabView there seems to be a lot of trial and error and experimenting, especially as it relates to the UI.