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 Charles wrote:
> 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.
>
Well need to see code on how you are starting your splash screen and
other startup code.

Chris

On 21 May 2006 15:23:51 -0700, "Graham Charles" <(E-Mail Removed)>
wrote:

>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.

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 Charles" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> 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.
>

On Mon, 22 May 2006 08:42:18 +0200, "Cor Ligthert [MVP]"
<(E-Mail Removed)> wrote:

>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
>

I think you completly misunderstood the OP's post.

Gene