FWIW, I created a feedback report: <https://xojo.com/issue/49326>
Please sign on if this is an issue that poses a problem for you. Thanks.
As an OS timing/queueing thing, I’m not sure how much Xojo can do.
It would be beneficial on multiple levels to thread your initialization sequence, which would free up your Window to update and display. Alternatively the timer method I mentioned earlier should also alleviate the stress of App.Open
Essentially, though, you should move this complex procedure out of the App.Open event.
While only partially related; unless the product updates are critical to the usage of the application. I wouldn’t recommend making the user wait while you check for an update. The reason being is that there literally a thousand things that can go wrong between your code and your server, the worst case scenario is that the update check takes a few minutes… thus preventing your user from doing anything.
I am afraid you simply don’t understand what a timer can do. Currently halting the main thread simply freezes execution, which a timer will not do. Freezing execution on the main thread means that all the maintenance in the main thread you describe simply cannot take place until the pause is over. That is not the proper way. If you need more time, simply change the timer period. But hey, you have the right to be wrong and insist on it. That is your app, after all.
Filing all the bug reports because you code is ill formed won’t fix it BTW.
If you have other stuff to do while the splash screen is showing then you don’t need the timer at all. In App.open do:
'show splash screen
'do init stuff
'close splash screen
Correct. I’m using an HTTPSocket asynchronously to check for updates. The call to check for updates is part of the initialization code in App.open, but an unresponsive server won’t hold up execution.
Yes, I understand that. As I mentioned before, my code doesn’t freeze the main thread. The line SleepCurrentThread(2000) in the example is merely meant as a substitution for a bunch of things that may take about 2 seconds to complete before the app is ready to use, and I want to inform the user somehow of what is going on. A splash screen should be an acceptable way to do that. After all, Xojo does the same thing with their IDE.
[quote=347463:@Beatrix Willius]If you have other stuff to do while the splash screen is showing then you don’t need the timer at all. In App.open do:
'show splash screen
'do init stuff
'close splash screen[/quote]
Yep. That is EXACLTY what I’m currently doing, and since upgrading to High Sierra the splash screen no longer shows.
I think @ Tim Parnell’s suggestion of moving the initialization to a thread and controlling the splash screen contents via a short timer is probably the best solution.
I’m not filing a bug report because my code may or may not be ill formed. I’m aware that managing a splash screen from the app.open event may not the best way to this ever. I’m filling the report it because something that has worked across all all platforms just fine for the last 10+ years stopped working for one of the platforms since their latest OS update. I think this may be something the developers at Xojo might want to know about. If it turns out that there is nothing they can do because of how macOS now handles timing and queueing, then so be it, but at least someone brought it to their attention.
BTW: Xojo IDE shows an update window when you run Xojo and your version is not up to date; this update window let you decide if you want to updatee or not.
Also, but the context is different, Feedback force the update when your Feedback version is older (versus the current web server ?); is not the last. This is the first Feedback version that do that. Good reasons ARE behind this change. AND Feedback is special, but it can also be a model (depending on your application status / environment).