You need to start your heavy lifting in the event loop after the window has been drawn on screen, or you’ll lock the runtime before the window gets drawn. A timer on the splash screen with a time of 100ms to start the heavy lifting will work.
Splash screens work best with frame type: plain box.
Just for my own curiosity, for a window like a splash screen that will be used once (per app execution) and never seen again, what is the benefit of using the Activate event rather than the Open event for startup stuff?
before everything at the top of your Activate event in your splash screen it would force the paint and update the window before it got into the rest of the code underneath it. Refresh will always redraw the window/control before moving on from that call.
It depends how your code is written/program is designed. If you instantiate the window before you show it and the window visibility is set to False then the Open will fire before the user has actually “seen” the window. Where as the Activate event will fire when the splash screen is actually shown to the user.
Ok, that makes sense. In my case, I have an app that needs to read a bunch of data from an Excel spreadsheet, parse the data and fill a listbox. Since reading the Excel data takes so long and I didn’t want to present the user with a blank listbox (before populating it), I opted for a splash screen. I never saw the issues Dave was having, possibly because I set the splash screen as the default window for the App, and set it to implicit instance.
[quote=455893:@Tim Jones]Maybe we should share this with the Xojo team to get the Xojo splash screen to properly display on Linux at launch instead of AFTER the plugins are loaded …
It needs to be moved to be threaded at start up for various reasons
like this <https://xojo.com/issue/56200>
if you have a bunch fof plugins you can still open and create new projects while the splash screen is open and plugin are loading etc