Board index » delphi » Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?

Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?

In my app, I have a splash window that loads/shows at the beginning before
any other application forms are created and finally is freed when the login
dialog is activated.  On this splash window, I have a third-party progress
display control that shows a progress gradient moving back and forth (untied
to any actual progress)--a thread updates its display depending upon a set
interval.

On a workstation, I'm loading the app from a network drive; this workstation
has a slow connection to the network.  When I launch the app, the progress
display snags (for a second or two) with the load of the first "form",
actually a datamodule, then moves ahead a bit, then snags again with the
load of the second form, then moves ahead again.  There's nothing in the
OnCreate of these forms that causes this snag, to my knowledge.

I was thinking that if I could do an Application.ProcessMessages with the
loading/instantiation of each of the form's components/controls, then that
might prevent or ameliorate somewhat the snag I'm seeing in the progress
display.

First of all, I don't know of a way to trap the moment when the
loading/instantiation of any of the form's components takes place.  Any
thoughts?  Also, might there be another approach to resolving this issue?

Thanks in advance for any assistance.

Steve

 

Re:Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?


"Mike Williams (TeamB)" <mi...@remove.aps-soft.com> wrote in message
news:Xns930DA84F3BF5Bmikewteamb@207.105.83.65...

Quote
> On 24 Jan 2003, "Steve Magruder" <steve@steve{remove}magruder.com>
> wrote:

> > In my app, I have a splash window that loads/shows at the beginning
> > before any other application forms are created and finally is freed
> > when the login dialog is activated.  On this splash window, I have a
> > third-party progress display control that shows a progress gradient
> > moving back and forth (untied to any actual progress)--a thread
> > updates its display depending upon a set interval.

> Since the VCL is not thread-safe your thread must be doing a Synchronize
to
> allow the main thread to do the VCL updates.  If the main thread is busy
> loading resources over the network I don't think
> application.processmessages is going to make it do anything else any
> sooner.

Thanks Mike for your quick response.

The thread is indeed doing a Synchronize.  It's just that I was thinking
that if Application.ProcessMessages was called as each each discrete
resource within a form was loaded, then the snag would be reduced.  I
wouldn't mind it if the splash displayed longer because of this change if
the snags could be reduced.

By the way, assuming that doing this _did_ work, how could I write code
that's called upon the load/instantiation of each discrete resource in a
form?  (I thought I used to know the answer to this, but it's escaping me)

Regards,
   Steve

Re:Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?


On 24 Jan 2003, "Steve Magruder" <steve@steve{remove}magruder.com>
wrote:

Quote
> The thread is indeed doing a Synchronize.  It's just that I was
> thinking that if Application.ProcessMessages was called as each each
> discrete resource within a form was loaded, then the snag would be
> reduced.  I wouldn't mind it if the splash displayed longer because of
> this change if the snags could be reduced.

> By the way, assuming that doing this _did_ work, how could I write
> code that's called upon the load/instantiation of each discrete
> resource in a form?  (I thought I used to know the answer to this, but
> it's escaping me)

If the forms are only taking a long time to load over a slow network
connection that would imply that the forms themselves have a lot of
resources (like big bitmaps).  While this doesn't answer your specific
question about calling Application.ProcessMessages from a thread, I think
you might want to consider not having so many autocreated forms and for
those that do see if there's any way to make them use less space.

Alternatively, it appears that you may be able to use a non-VCL solution
(like writing directly to a locked canvas) from the thread that doesn't
require using synchronize.  The help for synchronize discusses things you
can do that are thread safe.

--
-Mike

Re:Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?


"Mike Williams (TeamB)" <mi...@remove.aps-soft.com> wrote in message
news:Xns930DDC9F27E6Bmikewteamb@207.105.83.65...

Quote
> On 24 Jan 2003, "Steve Magruder" <steve@steve{remove}magruder.com>
> wrote:

> > The thread is indeed doing a Synchronize.  It's just that I was
> > thinking that if Application.ProcessMessages was called as each each
> > discrete resource within a form was loaded, then the snag would be
> > reduced.  I wouldn't mind it if the splash displayed longer because of
> > this change if the snags could be reduced.

> > By the way, assuming that doing this _did_ work, how could I write
> > code that's called upon the load/instantiation of each discrete
> > resource in a form?  (I thought I used to know the answer to this, but
> > it's escaping me)

> If the forms are only taking a long time to load over a slow network
> connection that would imply that the forms themselves have a lot of
> resources (like big bitmaps).  While this doesn't answer your specific
> question about calling Application.ProcessMessages from a thread, I think
> you might want to consider not having so many autocreated forms and for
> those that do see if there's any way to make them use less space.

> Alternatively, it appears that you may be able to use a non-VCL solution
> (like writing directly to a locked canvas) from the thread that doesn't
> require using synchronize.  The help for synchronize discusses things you
> can do that are thread safe.

In the case of the app in question, I'm only autocreating one datamodule in
addition to the main form; all the other forms (and there's lots of them)
are created in code well after the intial launch and login.  The main form
is rather light, although it does contain one significant graphic (I need to
check its size).  The datamodule is of a moderate size.  (I don't have the
project in front of me at home, so I can't look up specifics)

I'll check into the "writing directly to a locked canvas" solution... sounds
intriguing.  Thank you.

Steve

Re:Splash screen "progress display" control stops due to form instantiation bottleneck - workaround?


its your slow network..
 have the splash screen in the main source file created and shown before
any of the others get created..
 at the end of the last form.create you can do what ever you want.
Quote
Steve Magruder wrote:
> In my app, I have a splash window that loads/shows at the beginning before
> any other application forms are created and finally is freed when the login
> dialog is activated.  On this splash window, I have a third-party progress
> display control that shows a progress gradient moving back and forth (untied
> to any actual progress)--a thread updates its display depending upon a set
> interval.

> On a workstation, I'm loading the app from a network drive; this workstation
> has a slow connection to the network.  When I launch the app, the progress
> display snags (for a second or two) with the load of the first "form",
> actually a datamodule, then moves ahead a bit, then snags again with the
> load of the second form, then moves ahead again.  There's nothing in the
> OnCreate of these forms that causes this snag, to my knowledge.

> I was thinking that if I could do an Application.ProcessMessages with the
> loading/instantiation of each of the form's components/controls, then that
> might prevent or ameliorate somewhat the snag I'm seeing in the progress
> display.

> First of all, I don't know of a way to trap the moment when the
> loading/instantiation of any of the form's components takes place.  Any
> thoughts?  Also, might there be another approach to resolving this issue?

> Thanks in advance for any assistance.

> Steve

Other Threads