After the software is opened, it always stays in the Harman interface

[bcliutong]

OS: windows10 64
SDK: AIR SDK For Windows 33.0.2.339
Publish Settings: Embedded Runtime Applications
My Problem: After the software is opened, it always stays in the Harman interface。This problem does not exist on my machine, but on the other two machines.

[ajwfrost]

Hi

The request to hide the splash screen comes after we've processed the ActionScript for the first "frame", before rendering it. So this could happen sometimes if there's an exception thrown within your main class constructor - normally it would just mean you end up with an application with a white screen, but it looks like this would also leave this window up..

Are you able to run Scout before you start the AIR application, and see whether there are any clues provided in the Scout output about what may be happening during the application start-up? And do you have any ANEs, because another common issue is if an ANE fails to load then this could be the result..

thanks

Andrew

[2jfw]

Maybe adding an UncaughtErrorHandler logging/writing error to file?

[WEMcode]

This is very interesting I have a similar problem and it happens on 33, 50 and 51 latest versions. Oddly the app runs in shell/kiosk mode on windows11. Starting explorer.exe frees up the hang for some odd reason.

If I understand correctly - I should defer application startup tasks away from the constructor those to added to stage. Problem is I don't get an application with an empty screen. I get nothing loading in. No pre-starling stage at all. air v32 works without this hang.

To add, I have different experiences on different win 11 machines that were spec'd identically.

[WEMcode]

Also added an UncaughtErrorHandler as suggested by @2jfw - unfortunately no error was caught in the start up of the application.

[ajwfrost]

Hi

Thanks for the details. The splash window is actually launched as a 'topmost' window so that kind of makes sense.

We've added some logging into the runtime so would you be able to place the DLL with the one from the below message and then re-try it? There's a possibility it may actually work this time as we added a slight logic change - but the log would tell us if this made the difference.

If it does hang, please just kill it (after only a few seconds otherwise the log could get big!) and we should then be able to see from the log where it's hanging.

Log file will be written to the current user's "Documents" folder e.g. c:\users\username\Documents\air.log

thanks

Andrew

https://transfer.harman.com/message/GTM6cpitt2XzVMUSVKGunm

[WEMcode]

air.log

That seems to have tackled the hang! 👏👏👏

I ran this both on my staging machine where there was no hang and on the hanging production machine.

The hang machine's log has distinct debug entries but as you suspected the splash screen proceeds to the application.🎉

Hang Machine Log:

Splash wndproc -> WM_TIMER (123, 68269609)
Spent too long in initial loop -> Invalidate?
Splash message received -> f (waiting for f)
Splash wndproc -> WM_PAINT
Request to hide splash hwnd = 1015e
Splash timeout -> destroying splash window

Splash wndproc -> WM_DESTROY

Working Machine Log:

Waiting for splash timeout, message is 113
Splash wndproc -> WM_TIMER (123, 68003265)
Splash timeout -> destroying splash window

Splash wndproc -> WM_DESTROY

[ajwfrost]

Thanks -> I'd actually be interested in the fuller log from the machine on which it was hanging, the attachment there doesn't have the "spent too long" line in it. The original idea was that the "display splash screen" method should return as soon as the splash screen is visible but for some reason that wasn't being detected hence the "hang", but a call to Invalidate() seems to have solved that.

The change we made in that version was a bit of a hack so to do that as a better solution, we could do with seeing the full log from the machine where it originally hung..

thanks

[WEMcode]

Understood.

The attachment has said log line and is from the machine that was originally hanging:

Line 326 has the "Spent too long in initial loop -> Invalidate?"

[ajwfrost]

Oh bizarre, apologies for not seeing that. I'm not sure why I had it in my head this was the already-working version...
So it looks like there was a paint event processed before we starting cycling through the event loop, I don't know how that's possible but probably some quirk of paint message handling in Windows. But having seen that, it's simple to then add a condition to ensure we don't get blocked by this scenario.

thanks