sorry if this has been mentioned before, but wanted to put it out there while I had a second…
wouldn’t it make sense to make the splashscreen class a thread? i.e. subclass of Thread?
Seems a splash screen is only useful when:
a) It provides some feedback on the progress of loading / initializing the main application (process), and
b) You can get rid of it when it’s blocking access to other applications while your waiting for said main application to finish all it’s init stuff.
Neither of which can be accomplished if it’s part of the main process / thread.
perhaps this was the suggested usage anyway, and I just missed that part, but should be simple enough to drop into the splash class, and maybe provide some callback or variable to watch that the main process can update on a “percentage” basis… I forget the class name off the top of my head, but there’s some progress bar dialog that behaves this way… shouldn’t be any different really… no?
The splash screen’s just a component… If you want to do your startup tasks on a different thread, you’d just need to create your own thread to run them, but quite often I’ve found that a lot of the startup code needs to happen on the main thread anyway.
thx, although maybe I’m missing the point? I don’t want to move my startup code… it belongs in the main thread… I was only suggesting the splash screen be spawned as a separate thread… merely an “observer” of the main threads progress… and killable at any time.
I think the question he is asking is: how can he show a customized, animated SplashScreen (i.e., with a progress bar or something) while his program loads? I am running into that same issue which is how I found this thread.
Basically, in my JUCEApplication::initialise function I want to show a SplashScreen first thing, and then have it repaint with different content, as my startup code (in my main thread) moves along. The repaints will cause the Splash to show things like “initializing audio…” and then when that’s done, “initializing plugins…”, and so on.
How to do that? I’m not sure having a separate Thread will work, because a lot of my initialization code needs to be in the main thread.
Even if you have things that for some reason must be called on the message thread, you should still try to put all your lengthy startup code on a background thread. At the stage where it needs to do something on the message thread (I guess you mean plugin scanning or something), the background thread could use MessageManager::callFunctionOnMesssageThread to do it, but obviously keep that to a minimum.
