Animated splash screen won't animate while opening reference

[lgc102]

There is no caller for my loader - I was treating it as a top-level that launches the main app then closes itself.

In Dev, with everything closed except the project, right-click on the loader and "Run", I see the same behavior.

If I open the loader vi and run it with the project closed I see the same behavior.

Building application with loader as top-level and main vi as always included, I see the same behavior.

Not sure if that passes the sanity check. Or if I pass it at this point...

-Lou

---

@JÞB wrote:

Just as a sanity check. When you use the ACBR method, The caller vi "!gtoLoader.vi" is in run mode with the BD closed right?  In other words there is a caller for your loader

This note from the Help on the call configuration dialog box explains why

[image cut]

---

[lgc102 · Accepted solution]

An update to wrap this up.

The "why" of this was answered by a private message - it's a Root Loop problem. Basically the Open Reference will always supercede all other activity, and there's nothing to do about it unless it can be called by name. Using a static reference instead of Open VI Reference seemed to help a little, but that was overshadowed by the real cause of the delays.

The real cause was that it takes 30-60 seconds for the combination of Windows loading the 8.5MB exe file over our network and LabView Runtime to load all the dependencies (500+ subVIs and 22 lvlibs).

So, solved by using two exe files, a simple "loader" application, containing my animation and a call to System Exec.vi that launched the exe version of my main application (and passed cmd line args to it). Modified my main application so that when it initializes, it closes the loader window using Win APIs (see How Can I Close a Windows Application with LabVIEW?).

Could not have gotten this to work without the answers and suggestions - thank you to all.

[Yamaeda]

A slight variation would be to use the Find Window in the launcher, so it closes itself when the target has launched.

/Y

[Hooovahh]

So I had a similar issue a while back.  One of my goals was to provide a cancel button on the splash screen, and to show the modules that were being loaded.  In my case each code module was in a library, similar to how the Actor Framework breaks up the application into classes.  So I had a progress bar showing each library getting loaded, and in between loading I had a small delay which would poll the cancel button and update the progress bar.  Without this 1ms delay between loading modules I had the UI lock up like you described due to the root loop.  I posted my example over on LAVA here.  Having an EXE launch an other EXE is another solution of course, but this method allows me to have just a single EXE to build.  The down side of course is the pre-build VI that needs to know a bit about your software design.

[lgc102]

---

I had looked at that thread, but didn't get more than partway through, and stopped after this approach didn't do what I needed. Now that I read it through to the end, there was more there than I thought. It'll be a while before I can try to digest the example you posted, as the actor framework is (ashamedly) unfamiliar to me.

From your description, that's a more elegant approach.

A colleague had sent me an example of something similar - she works on a much higher plane of LV than I do, and uses it in her code which is a multi-factory framework. Her example opened a ref to top-level VI, then iterated over the string array returned from App.AllVIs loading each one with a status display (among other things). 

When I tried this with mine, I ran into delay issues - behaved right in development, but once I built it into a single exe, the delay to load the exe before the animation showed up was long enough to make me want to double click again, hence the double exe. 

@Hooovahh wrote:

So I had a similar issue a while back.  One of my goals was to provide a cancel button on the splash screen, and to show the modules that were being loaded.  In my case each code module was in a library, similar to how the Actor Framework breaks up the application into classes.  So I had a progress bar showing each library getting loaded, and in between loading I had a small delay which would poll the cancel button and update the progress bar.  Without this 1ms delay between loading modules I had the UI lock up like you described due to the root loop.  I posted my example over on LAVA here.  Having an EXE launch an other EXE is another solution of course, but this method allows me to have just a single EXE to build.  The down side of course is the pre-build VI that needs to know a bit about your software design.

---

[lgc102]

I like that. If I ever genericize this into something reusable, will do it that way.

---

@Yamaeda wrote:

A slight variation would be to use the Find Window in the launcher, so it closes itself when the target has launched.

/Y

---