Splash subclass not forking correctly when called from SessionManager subclass ?

Friends,

I am porting my splash screen logic over from 3.x to 4.x.

I have implemented a subclass of SessionManager, and it contains its own
"main" method, which, prior to opening the main shell of my app, shows a
splash screen for 1.5 seconds. If I evaluate the code in 4.0 before
packaging, it works fine.

However, after packaging, when the app is coming up, the splash screen
stays up until the entire "main" method is finished.

KenSessionManager>>main
    (KenSplash new bitmap: (Bitmap fromId: (KenStuff appName, '.bmp')))
        showTimed: (Delay forSeconds: 1.5).
    KenMainShell run.

I should point out that the "KenMainShell run" method first brings up
the KenMainShell, and then opens a disk file and loads that file into
the app, all of which can take as long as 10 seconds. What I see is that
the splash screen hangs around for those 10 seconds.

Perhaps there is an issue here concerning the priority of different
threads ?

As always, I would be most grateful for any help or insights.

Best wishes,

Ken Lee

Ken,

> I am porting my splash screen logic over from 3.x to 4.x.
> [snip]
> I should point out that the "KenMainShell run" method first brings up
> the KenMainShell, and then opens a disk file and loads that file into
> the app, all of which can take as long as 10 seconds. What I see is that
> the splash screen hangs around for those 10 seconds.
>
> Perhaps there is an issue here concerning the priority of different
> threads ?

I'm not in the best position to comment because: (1) my 4.0 executables are
not yet in production use (getting close though); (2) I wrote my own
framework for this kind of stuff a long time ago, and it still works, so I
have not bothered to change anything.

With that said, I'd expect you to get worried if things were the other way
around.  My code puts up a splash screen late in #secondaryStartup (the
earliest opportunity) and signals its semaphore late in #tertiaryStartup,
after the app is ready to go.  With the addition of overlapped calls, one
has to ensure that the main UI thread is running before making any
overlapped calls, so I run all of my startup logic from a deferred action
that waits on a sempahore signaled from the startup code.  My hat's off to
OA for  being able to substantially refactor the session managers w/o
breaking my framework.

That's a long path the following point: my goal was to create something that
put up a splash screen that stayed not for a fixed duration, but, until the
app was ready to go.  I assume OA had that same thing in mind.  I'm not sure
exactly what's preventing you from getting a fixed time, though again, I
think its more useful to close the splash screen when the app is ready for
the user.

The last time I had to look at these things, Dolphin used a high priority at
startup to "outrun" the leftover UI thread from the previous session: in the
case of  deployed app, that's the development session that deployed it.  You
could, as you point out, be suffering at the hands of a higher priority
thread.  It's also possible that your splash screen is "closing" on queue
but the view that's uncovered is not getting repainted until the startup
tasks are complete.

I hope something in the above is helpful.

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Ken,

I don't know whether this will fix the problem, but have you tried
overriding the GUISessionManager>>showSplash method. This is new in Dolphin
4.0 and is the recommended way of putting up a splash screen for a deployed
app. If you still have problems let us know and we'll take a look.

Best Regards,

Andy Bower
Dolphin Support

"Ken Lee" <[hidden email]> wrote in message
news:91ftp6$43l08$[hidden email]...