Jump to content

Splash Screen Woes


MartinMcD

Recommended Posts

Hello there,

I have set a splash screen as the startup vi in an application. The splash screen then launches the main application window with a vi server call. Once the main application has loaded in generates a user event which the splash screen picks up and so closes itself down using a Front Panel.Close call.

When I am working with the development environment and not the built executable it all works fine. However, when run from the build exe, it still works but now I end up with two icons called 'Prog X' on my start bar which looks a bit rubbish.

I can sort of see the reason I think - in the built version the splash and main app windows both have the same title which is the application name, when in the dev environment they have different names. It seems that Windows can't figure out what to do.

Due to our firewall I can't upload images to the site, from my explanation does anyone have any ideas or has anyone come across anything similar?

Thanks very much,

Martin

Link to comment

A small tip about splash screens:

Having the splash screen launch the main program is not always ideal as it prevents you from disabling the splash screen if needed (we have to do this for customers who run our apps on terminal servers e.g. - to save bandwidth (or at least many prefer it that way).

A more flexible solution is to launch the splash screen from the main instead - but hide the main until the splash screen has closed. To do this optimally LabVIEW should offer us the possibility to set the run-time state of VI windows to "Hidden"...but that's not available so the next best thing is to set it to minimized...and then hide it immediately by running the necessary method (hardly noticable...unlike if you had shown the window in normal size and then hidden it). This way the main program can check if it is supposed to show a splash screen or not - and if it is - it will hide itself and then launch the splash VI....if it is not - it will just normalize or maximize itself and continue.

Mads

Link to comment

A small tip about splash screens:

Out of interest...

I haven't programmed for that bandwidth constraint so conversely I like to launch the Splash Screen (as the Top Level VI) which will then go on to dynamically load the Main Application then go out of memory. This way I can do any prechecking e.g. is required supporting software installed (e.g. Dot NET, DAQmx) - which if missing may cause the Main Application to be broken. So my aim is to prevent launching a broken Main App. Also I can run any bootstrap logic that may cause the Main App's GUI not to be shown (e.g. misisng/corrupt support files etc...) and for the Main App to be shutdown immediately. Lastly I can initialise the Main App's GUI before showing it (as you mentioned). I too configure the Splash Screen in the same way you described for the Main App.

Link to comment

I understand. The optimal solution if you need the functionality that you descibe is probably to split the splash into an optional GUI (the visible splash screen) - and a loader. The latter is the top-level VI of the app, and it will hide itself and do the necessary prechecks etc. in the background. The loader will only launch the visible splash screen if this is enabled.

The "GUI" of the splash screen then also becomes a VI you can use as an About Box e.g. :-)

Mads

Out of interest...

I haven't programmed for that bandwidth constraint so conversely I like to launch the Splash Screen (as the Top Level VI) which will then go on to dynamically load the Main Application then go out of memory. This way I can do any prechecking e.g. is required supporting software installed (e.g. Dot NET, DAQmx) - which if missing may cause the Main Application to be broken. So my aim is to prevent launching a broken Main App. Also I can run any bootstrap logic that may cause the Main App's GUI not to be shown (e.g. misisng/corrupt support files etc...) and for the Main App to be shutdown immediately. Lastly I can initialise the Main App's GUI before showing it (as you mentioned). I too configure the Splash Screen in the same way you described for the Main App.

Link to comment

I understand. The optimal solution if you need the functionality that you descibe is probably to split the splash into an optional GUI (the visible splash screen) - and a loader.

Thats exactly what I do :)

I normally configure an engine that does all the real work (checking and loading) and the Splash GUI just sits on top of it.

I also have an engine that I can reuse for simple apps, and a template for the splash screen, so I can slot it in pretty quick.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.