Animated splash screen won't animate while opening reference

[lgc102]

Made an animation with a set of Pict Rings to show as a splash screen while my main application exe loads and launches (loader vi attached), and was frustrated to find that the images don't change until the target is loaded.

It seem like there are no front panel updates while the Open VI Reference is processing (?), and by the time it processes it's already done. Tried forcing front panel updates , putting the launch code into another thread by putting it into another subvi launched asynchronously, and nothing worked.

I found (I think) that the timeout case here only fires once, then no more code is executed until the Open VI Reference node is passed, but I cannot figure out why.

What am I missing? Should I just give up on having the fancy animation, just use a boring still image?

help...

[altenbach]

Have you tried to just use an animated gif on the front panel instead?

(not sure if it would work...)

[lgc102]

I did try that. Same thing happened.

I plopped a test gif on the front panel by loading to clipboard and pasting, didn't make it into a control.

[JÞB]

Mark Ridgley has a nice example on the community side

[lgc102]

---

@JÞB wrote:

Mark Ridgley has a nice example on the community side

---

I had looked at his examples (which are nifty), but they didn't work for me the first when I tried to drop it in my main app. Tried it again, dropping it into the loader this time, and have the same behavior. The Open VI Reference call prevents any front panel updates and prevents the Timeout event from tripping, even though it's not in dataflow sequence with the animating code.

Tried to make a cleaner demonstration of this to post, but just trying to open a 10MB subvi doesn't cause the problem, looks like the slow Open VI Reference behavior is caused by loading the 500+ internal references & subvis.

The delay I'm trying to cover up is the time it takes for my 8.5MB .exe file to load over the network (about 30-45 seconds). Once the main vi is running, there's no other delays to cover up (subsystems load and check very fast). I'm trying to have it show something right after user double clicks, so they don't double click a half dozen times thinking it didn't work, and thought I could use a loader to show the animation then call the main program dynamically.

Only thing I've come up with that seems to work is to build the loader as an exe, then have it launch via commandline the built exe for the main program. This makes it awkward because the main app cannot tell the loader now when it's done loading, so user has to close the loader, or the main app has to look for the loader splash screen and close it somehow. Seems awkward and kludgy.

-Lou

[Yamaeda]

Ah, the Splash screen problems ...

I recently had a similar problem and my solution was to use a "Interface loader". I did a Splash that had a static VI ref to my target and all froze because the static vi ref loaded all ... (i don't understand why it should do that, that's what the Open VI block is for ...).

Create an Empty VI with the same input/outputs as your target VI, and use that as Type for the Open VI.

/Y

[lgc102]

Like this? 

If so, it didn't work: got error 1000 "VI in a state not compatible with this operation".

And there was still a long lag.

My main VI has no inputs or outputs.

More info: adding an iteration display to the upper loop shows me that about 50 timeouts are handled while the Open Ref is processing, but the screen is not redrawn between iterations 2 and 53. Does Open VI Ref freeze all UI's while it's processing?

---

@Yamaeda wrote:

Ah, the Splash screen problems ...

I recently had a similar problem and my solution was to use a "Interface loader". I did a Splash that had a static VI ref to my target and all froze because the static vi ref loaded all ... (i don't understand why it should do that, that's what the Open VI block is for ...).

Create an Empty VI with the same input/outputs as your target VI, and use that as Type for the Open VI.

/Y

---

[Yamaeda]

(Almost) exactly like that, just add Option 0x8 (Octal 😎 for Reentrant run. 🙂

You could also try to make a subvi of the open VI and set it to run in another thread, that might help with the front panel update.

/Y

[lgc102]

---

@Yamaeda wrote:

(Almost) exactly like that, just add Option 0x8 (Octal 😎 for Reentrant run. 🙂

You could also try to make a subvi of the open VI and set it to run in another thread, that might help with the front panel update.

/Y

---

With 0x8 option wired, I now get error 1096: The Open VI Reference function cannot prepare a non-reentrant VI for reentrant run. If I make my main VI re-entrant, it runs but the panel still freezes during Open Ref. With 0x80 I get the Error 1000 again.

A colleague suggested making a subvi from the Open VI with a different execution subsystem - this didn't help it either, even if I launched the sublauncher asynchronously and the sublauncher was set to run in a different execution subsystem.

Only thing I've gotten to work is the built exe calling another built exe via the command line prompt (ick).

I assume you mean hex 8, as octal 8 doesn't really exist...

-Lou

[JÞB]

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