MartinMcD Posted November 25, 2010 Report Share Posted November 25, 2010 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 Quote Link to comment
mabe Posted November 25, 2010 Report Share Posted November 25, 2010 Hi, Did you tried to add the key "hiderootwindow=true" in the INI file of your EXE? Mathieu Quote Link to comment
MartinMcD Posted November 25, 2010 Author Report Share Posted November 25, 2010 Sweeeet! That is fantastic thanks so much. Best regards, Martin Quote Link to comment
jgcode Posted November 25, 2010 Report Share Posted November 25, 2010 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. Hi Martin You already posted this question a few months ago! Quote Link to comment
Mads Posted November 26, 2010 Report Share Posted November 26, 2010 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 Quote Link to comment
jgcode Posted November 26, 2010 Report Share Posted November 26, 2010 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. Quote Link to comment
MartinMcD Posted November 26, 2010 Author Report Share Posted November 26, 2010 Hi Martin You already posted this question a few months ago! Doh! I can be pretty forgetful... Quote Link to comment
Mads Posted November 27, 2010 Report Share Posted November 27, 2010 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. Quote Link to comment
jgcode Posted November 27, 2010 Report Share Posted November 27, 2010 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.