Splash screen launcher

[jwp@astro.wisc.edu]

I've read various threads on splash screens, and received (as always) very useful help from the NI engineers, but I'm still trying to get exactly this, which I think requires me to set the Z-order (stacking order) of windows. Here is my vision:

1. use fires up "manager.vi". It sits there centered.

2. user clicks the "run tool" button.

3. A splash screen (picture) appears, completely covering the manager window.

4. Unbeknownst to the user, I open up "tool.vi", but would like it between the splash and the manager. That is, splash on top, then tool, then manager.

5. The splash increases its transparency over a few seconds, becoming invisible, revealing tool.vi.

6. when the user closes tool.vi, there is the manager again.

I nearly have this, but my tool.vi appears all of a sudden after the fade is done. I haven't been successful in opening it up discreetly under the splash. I just can't seem to hit the right magic with hidden, active, etc. I attach my manager vi, hoping it's clear enough.

[aputman · Accepted solution]

Maybe instead of covering the manager window, you could make the VI not visible but still running.  Start the Splash screen when the button is click.  Inside the splash vi, call the tool vi asynchronously.  Pass a notifier reference and a reference to manager VI into the tool VI so you can communicate between the splash and tool VI.  when the tool VI finishes initializing, make the front panel visible and close the splash VI.  When the tool VI is closed, the manager is made visible again using the reference.  That way, you aren't managing multiple open windows and worrying about the z-order. 

[jwp@astro.wisc.edu]

This is a great suggestion, and tells me about techniques I wasn't aware of. In my final implementation, though, I have used Application Builder to build manager.vi into a Windows .exe file. From what I'm reading about notifiers, my options for inter-process communication are more limited than in the usual LabVIEW application instance? I had tool.vi and splash.vi appearing in the block diagram of manager.vi, so that in the final executable build for Windows, there would be only be one process involved.

[aputman]

I did not realize you have multiple executable files.  If you plan to leave it as separate executable files (probably not the best solution unless tool can be called from other EXEs, similar to a plugin), use a command prompt within the manager VI to call the tool executable.  Set the command prompt to wait until completion, and hide the manager.  When the tool executable is complete, execution will return to manager where you make it visible again.  

If the tool EXE is separate, you may need to consider that the user double clicks this EXE on their own, rather than thru manager.  What happens?  This is why I say it may not be the best solution.  

The tool executable would be structured similar to what i describe above.  The startup VI would be set to the splash screen which calls the tool VI asynchronously, passing in a notifier reference to communicate back to splash screen that the tool VI is loaded and ready to display.  You can even use the notifier to send status messages back about the initialization process ("Building UI", "Loading Config Settings" etc.)  These can be displayed to the user and make a nice looking and informative loading screen.  Some of these initialization routines happen really quickly so you may want to add a pause for effect.  All of this really only works well if you have a good architecture setup for the tool VI (preferably a state machine, IMHO).  

[jwp@astro.wisc.edu]

Thanks so much for your advice! I appreciate it a lot. I'll go off and study the various things you describe, and improve the architecture of my program. This forum is a great source of help.

[aputman]

This is how I have my splash VI coded and it works great.  The code in the sequence structure is to grab the EXE revision and update it on the splash screen before it is presented to the user.  You may not want/need that bit.

Looks like I have a 30sec timeout for the splash screen.  Not sure why I did that but it could be useful if your main VI fails to initiate for some reason. 

[jwp@astro.wisc.edu]

Hello again! I studied your block diagram, and learned some new stuff! I coded up a slightly simpler VI, excluding the helpful "Loading..." notifications, but in my version, my tool.vi (playing the same role as your teststand.vi), the tool's front panel never opens. When I open the tool.vi from my project window, it opens up already in the run state. I think this is due to the asynchronous call, maybe?

-Jeff

[aputman]

What does tool.vi settings look like?  What are the execution settings?  In order to prevent the VI from starting when clicked in the project, "Run When Opened" should be turned off. Start Asynchronous Call will run your VI for you.  Also make sure that "Show front panel when called" is unchecked.  You'll want to make the front panel visible at just the right moment via code.

Your splash screen closes after 5 seconds.  I assume that was just a temporary method that you were trying out.  The purpose of a splash screen is to hide the lag-fest associated with starting an app, meaning that the tool.vi should tell the flash screen when to close, not the other way around.  And I did that via the notifier.  The wait on notification should be looking for a specific message that is the signal to exit the loop and close the splash.  This means that tool.vi should send that message at some point (after 5 seconds, if you like, or at the end of an init routine).  In my code, if a timeout occurs at that Wait on Notification, it means that the main.vi never started or is stuck somewhere or is taking longer than expected to startup.  

My teststand.vi has an init routing that runs on startup.  The last step in the init routine is to send the "Done" message to the splash.vi (which closes the splash screen) and makes the teststand front panel visible. (FP.Open invoke node). 

[jwp@astro.wisc.edu]

Hi! Each of your replies is very helpful to me. You mention the FP:Open invoke node, but I don't see that in the block diagram you included with your original reply. This sounds like just what I need! Is that final "FP.Close" supposed to be a FP:Open on the tool VI reference? I did experiment with changing the final FP:Close to a FP:Open, (before closing the reference) and I saw pretty much what I had hoped to see!

You are right that my simplifications were just temporary, to get the general idea. I really like to handshake via notifications. I would never have thought of that!

-Jeff

[aputman]

I made a quick example for you to play with.  Main.vi uses the JKI State Machine template, which I highly recommend if you need a state machine architecture.