AppStartup "Cancel" leaves splash form loaded

  • Thread starter Thread starter Graham Charles
  • Start date Start date
G

Graham Charles

Hello,

I'm finding that if I set the "Cancel" property during the AppStartup
event, the application's Splash form remains loaded.

A call to the Close property of the SplashForm at that point returns a
cross-threading error, since (it appears) the Splashform is loaded by a
different thread.

Any advice? I could ignore the SplashForm application setting and just
load it myself, I suppose.

Thanks,

g.
 
Graham said:
Hello,

I'm finding that if I set the "Cancel" property during the AppStartup
event, the application's Splash form remains loaded.

A call to the Close property of the SplashForm at that point returns a
cross-threading error, since (it appears) the Splashform is loaded by a
different thread.

Any advice? I could ignore the SplashForm application setting and just
load it myself, I suppose.

Thanks,

g.
Click to expand...
Well need to see code on how you are starting your splash screen and
other startup code.

Chris
 
Hello,

I'm finding that if I set the "Cancel" property during the AppStartup
event, the application's Splash form remains loaded.

A call to the Close property of the SplashForm at that point returns a
cross-threading error, since (it appears) the Splashform is loaded by a
different thread.

Any advice? I could ignore the SplashForm application setting and just
load it myself, I suppose.

Thanks,

g.
Click to expand...

I ran across a couple of articles a few months ago that claimed that
this is a bug. As the event fires before the startup form, itself, is
created, it "should" logically fire before the splash form is created.
Logically, you would use the startup event to evaluate some condition
or conditions the result(s) of which dictate whether or not the
application should run. If the result(s) is no, setting the Cancel
argument to True ends the startup and precludes the application from
running. It therefore makes no sense to even display a splash screen
prior to running any condition code in the event.

One suggested alternative (which I use) is:
1) Not specify a splash screen in the project
2) Show a SplashForm as the last line of code in the Startup Event.
3) Make the MainForm visible ASAP in the LoadEvent
4) Continue with LoadEvent code execution
5) Close the SplashForm at the end of the MainForm load event. This
line can optionally be preceded by a Thread.Sleep statement which can
be used to adjust the display time of the SplashForm.


Another example I ran across suggests to use the Project specified
SplashScreen and simply add an End statement after Cancel is set to
True, the argument being that this is one instance where it is safe to
use "End". It does work, but I prefer the other method.

Gene
 
Graham,

Who gives you the right to let the user not cancel a splash screen.
I would call this a major bug in your program if I had to use it and that is
not possible.

One of the SP parts of Internet Explorer is to prevent that this could be
done.

Just my thought,

Cor
 
Graham,

Who gives you the right to let the user not cancel a splash screen.
I would call this a major bug in your program if I had to use it and that is
not possible.

One of the SP parts of Internet Explorer is to prevent that this could be
done.

Just my thought,

Cor
Click to expand...

I think you completly misunderstood the OP's post.

Gene
 
Back
Top