Slplash Screens - Loading Data

[Ken K]

I want to load data during the display of a splash screen. I am using a Dialog
for the splash. If I start the load during InitDialog, the screen isn't
painted until the load is done. Any suggestions as to when (or how) to start
the data load after the screen has been completely painted? (other than setting
up a timer?)

Ken.

[chris]

"Ken K" <kkirkhope@cougartool.com> wrote:
>
>I want to load data during the display of a splash screen. I am using a
Dialog
>for the splash. If I start the load during InitDialog, the screen isn't
>painted until the load is done. Any suggestions as to when (or how) to
start
>the data load after the screen has been completely painted? (other than
setting
>up a timer?)
>
>Ken.

take the responsibility for the data xfer out of the gui. use one thread
to control the lifetime of the splash and another to perform the work. then
signal the splash thread from the worker thread when the work is done so
that it can kill the splash.

[Paige]

"Ken K" <kkirkhope@cougartool.com> wrote:
>
>I want to load data during the display of a splash screen. I am using a
Dialog
>for the splash. If I start the load during InitDialog, the screen isn't
>painted until the load is done. Any suggestions as to when (or how) to
start
>the data load after the screen has been completely painted? (other than
setting
>up a timer?)
>
>Ken.


If you create a new thread for loading the data, then the data will load
regardless of the state of the splash screen. You could measure how long
it takes on average to load the data (lets say 2.5 sec) and then use that
time (maybe add a second to it for safety) to create a timer to control the
splash screen in the original thread, or just put the original thread to
sleep for 3.5 seconds after you load the splash screen.

In other words, the Splash screen would open in the original thread and then
automatically close after 3.5 seconds. The new thread would load the data
and then terminate. Also, if you needed to communicate between the 2 threads,
you could send messages back and forth using commands such as ::Peekmessage,
::GetMessage, and ::PostMessage (or ::PostThreadMessage if you know the thread
ID).
Here are the Declaration statements for those API functions:

---------------------------------------------------------------
Public Declare Function PeekMessage Lib "user32" Alias "PeekMessageA" (lpMsg
As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
As Long, ByVal wRemoveMsg As Long) As Long
---------------------------------------------------------------
Public Declare Function GetMessage Lib "user32" Alias "GetMessageA" (lpMsg
As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
As Long) As Long
---------------------------------------------------------------
Public Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal
hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As Long)
As Long
---------------------------------------------------------------
Public Declare Function PostThreadMessage Lib "user32" Alias "PostThreadMessageA"
(ByVal idThread As Long, ByVal msg As Long, ByVal wParam As Long, ByVal lParam
As Long) As Long
---------------------------------------------------------------

I hope this information is helpful.

Paige Ake
Software Engineer

[chris]

"Paige" <paige_ake@hotmail.com> wrote:
>
>"Ken K" <kkirkhope@cougartool.com> wrote:
>>
>>I want to load data during the display of a splash screen. I am using
a
>Dialog
>>for the splash. If I start the load during InitDialog, the screen isn't
>>painted until the load is done. Any suggestions as to when (or how) to
>start
>>the data load after the screen has been completely painted? (other than
>setting
>>up a timer?)
>>
>>Ken.
>
>
>If you create a new thread for loading the data, then the data will load
>regardless of the state of the splash screen. You could measure how long
>it takes on average to load the data (lets say 2.5 sec) and then use that
>time (maybe add a second to it for safety) to create a timer to control
the
>splash screen in the original thread, or just put the original thread to
>sleep for 3.5 seconds after you load the splash screen.
>
>In other words, the Splash screen would open in the original thread and
then
>automatically close after 3.5 seconds. The new thread would load the data
>and then terminate. Also, if you needed to communicate between the 2 threads,
>you could send messages back and forth using commands such as ::Peekmessage,
>::GetMessage, and ::PostMessage (or ::PostThreadMessage if you know the
thread
>ID).
>Here are the Declaration statements for those API functions:
>
>---------------------------------------------------------------
>Public Declare Function PeekMessage Lib "user32" Alias "PeekMessageA" (lpMsg
>As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
>As Long, ByVal wRemoveMsg As Long) As Long
>---------------------------------------------------------------
>Public Declare Function GetMessage Lib "user32" Alias "GetMessageA" (lpMsg
>As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
>As Long) As Long
>---------------------------------------------------------------
>Public Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal
>hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As
Long)
>As Long
>---------------------------------------------------------------
>Public Declare Function PostThreadMessage Lib "user32" Alias "PostThreadMessageA"
>(ByVal idThread As Long, ByVal msg As Long, ByVal wParam As Long, ByVal
lParam
>As Long) As Long
>---------------------------------------------------------------
>
>I hope this information is helpful.
>
>Paige Ake
>Software Engineer
>
>
why are you giving him vb prototypes? this is a c++ group...

also, killing the splash after a hard coded time is not good. different
machines in different environments will process at different speeds. it
is much better to signal btwn threads to synchronize thread behavior.

also, the use of the message pump to communicate requires that the app have
a message pump....many apps, even those on win32, are not gui...giving such
an app a message pump is usually kludgy at best. much better to use other
mechanisms to communicate. i would use an event in this case. if more robust
communication was necessary, i would use a callback interface (abstract base
class) to the app owning the splash. for example, if you wanted to display
progress in a bar...

-- chris

[JT]

"chris" <chofstaedter@padcomusa.com> wrote:
>
>"Paige" <paige_ake@hotmail.com> wrote:
>>
>>"Ken K" <kkirkhope@cougartool.com> wrote:
>>>
>>>I want to load data during the display of a splash screen. I am using
>a
>>Dialog
>>>for the splash. If I start the load during InitDialog, the screen isn't
>>>painted until the load is done. Any suggestions as to when (or how) to
>>start
>>>the data load after the screen has been completely painted? (other than
>>setting
>>>up a timer?)
>>>
>>>Ken.
>>
>>
>>If you create a new thread for loading the data, then the data will load
>>regardless of the state of the splash screen. You could measure how long
>>it takes on average to load the data (lets say 2.5 sec) and then use that
>>time (maybe add a second to it for safety) to create a timer to control
>the
>>splash screen in the original thread, or just put the original thread to
>>sleep for 3.5 seconds after you load the splash screen.
>>
>>In other words, the Splash screen would open in the original thread and
>then
>>automatically close after 3.5 seconds. The new thread would load the data
>>and then terminate. Also, if you needed to communicate between the 2 threads,
>>you could send messages back and forth using commands such as ::Peekmessage,
>>::GetMessage, and ::PostMessage (or ::PostThreadMessage if you know the
>thread
>>ID).
>>Here are the Declaration statements for those API functions:
>>
>>---------------------------------------------------------------
>>Public Declare Function PeekMessage Lib "user32" Alias "PeekMessageA" (lpMsg
>>As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
>>As Long, ByVal wRemoveMsg As Long) As Long
>>---------------------------------------------------------------
>>Public Declare Function GetMessage Lib "user32" Alias "GetMessageA" (lpMsg
>>As MSG, ByVal hwnd As Long, ByVal wMsgFilterMin As Long, ByVal wMsgFilterMax
>>As Long) As Long
>>---------------------------------------------------------------
>>Public Declare Function PostMessage Lib "user32" Alias "PostMessageA" (ByVal
>>hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, ByVal lParam As
>Long)
>>As Long
>>---------------------------------------------------------------
>>Public Declare Function PostThreadMessage Lib "user32" Alias "PostThreadMessageA"
>>(ByVal idThread As Long, ByVal msg As Long, ByVal wParam As Long, ByVal
>lParam
>>As Long) As Long
>>---------------------------------------------------------------
>>
>>I hope this information is helpful.
>>
>>Paige Ake
>>Software Engineer
>>
>>
>why are you giving him vb prototypes? this is a c++ group...
>
>also, killing the splash after a hard coded time is not good. different
>machines in different environments will process at different speeds. it
>is much better to signal btwn threads to synchronize thread behavior.
>
>also, the use of the message pump to communicate requires that the app have
>a message pump....many apps, even those on win32, are not gui...giving such
>an app a message pump is usually kludgy at best. much better to use other
>mechanisms to communicate. i would use an event in this case. if more
robust
>communication was necessary, i would use a callback interface (abstract
base
>class) to the app owning the splash. for example, if you wanted to display
>progress in a bar...
>
>-- chris
>

Ken,

You can avoid the problems that come with multi-threading and process
synchronization
by making use of the modeless dialog. Unlike the modal dialog, which is
displayed until
acted upon by the user, the modeless dialog is displayed and then code execution
continues.

Paige is correct though about breaking this out of the GUI code. You might
try making a GUI class
and manipulating everything from the app's managing class, something like:


void AppClass::OnInit()
{
... // Init class elements (do the stuff you
expect to find in OnInit)
GUIClass.Init() // Load your resources,
etc.
GUIClass.ShowSplashScreen(); // Display the modeless dialog
DataClass.Load(); // Load your data
... // Do anything
else you need to
GUIClass.DestroySplashScreen(); // Must explicitely destroy the
dialog
// On with the rest
of the program
}

In this manner, you can "splash" the modeless dialog, load your data, and
then destroy the
dialog. Unlike the modal dialog, the modeless dialog *must* be explicitely
destroyed by its
owner.

Hope it helps,

JT