Discussion :

[olibara]

Bonjour


Pour une application qui met un certain temps a charger, j'ai mis en place un splash sous forme d'une form dialog que j'ouvre dans un thread

Ca marche asser bien sauf que sur certaines machines la fenetre splash reste affichée sur la fenetre principale de l'application si on ne force pas un refresh en baladant la souris

Quelqu'un aurait-il une idée pour forcer la disparition de la fenetre dans l'abort du thread ?

Merci de vos conseils

Code Voici en résumé le code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    // *************************************************************************************
    public static void Initialize()
    {
 
      Thread th = new Thread(new ThreadStart(Splash));
 
   // lancement du thread
      th.Start();
 
   // process de chargement long
      _application = new C_Application();
 
      th.Abort();
 
      System.Windows.Forms.Application.Run(_application._context.MainForm);
    }
    // *************************************************************************************
    public static void Splash()
    {
      Version v = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
      frmSplash sf = new frmSplash(v);
      sf.ShowDialog();
    }

[cybermaxs]

Salut,

C'est possible que ce soit juste un problème de refresh. As tu essayé de faire une Application.DoEvents ?

Une autre possibilité est qu'en fesant thread.abort, tu ne fermes pas la form. Il faut dans ce cas catcher un treadAbortException dans ta méthode pour correctement fermer la Form.

[olibara]

Salut cybermax

C'est possible que ce soit juste un problème de refresh.

C'est certainement un problème de refresh puisque ca marche sur certaine machine et quesur les autres il suffit de déplacer lasouris

N.B. oEvent ne change rien, j'ai déja essayé

Une autre possibilité est qu'en fesant thread.abort, tu ne fermes pas la form.

A mon avis non (cnf réponse plu haut)

[StormimOn]

Essaye avec un Show plutôt qu'un ShowDialog et un ManualResetEvent pour gérer la synchronisation plutôt qu'appeler Abort sur le thread.

Quelque chose comme

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
private static ManualResetEvent _reset;
 
public static void Initialize()
{
    _reset = new ManualResetEvent(false);
 
    // Lancement du thread.
    new Thread(Splash).Start();
 
    // On attend la fin du traitement.
    _reset.WaitOne();
    _reset.Close();
 
    // Démarrage de l'application.
    System.Windows.Forms.Application.Run(_application._context.MainForm);
}
 
public static void Splash()
{
    Version v = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
 
    // Affichage du Splash
    using(frmSplash sf = new frmSplash(v)) 
    {
        sf.Show();
 
        // Traitement long.
        _application = new C_Application();
 
        // Envoi du signal indiquant la fin du traitement long.
        _reset.Set();
    }
}

Mais on peut faire plus simple si tu ajoutes le traitement côté SplashScreen. Par contre il faudra que l'initialisation se fasse à l'appel d'une méthode de la classe C_Application et non plus sur le constructeur. Il faudra bien évidemment threader ça côté SplashScreen pour être propre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public static void Initialize()
{
    // Lancement de l'initialisation.
    _application = new C_Application();
    Version v = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
    Application.Run(new frmSplash(v, _application));
 
    // Démarrage de l'application.
    System.Windows.Forms.Application.Run(_application._context.MainForm);
}

[cybermaxs]

A mon avis non (cnf réponse plu haut)

Je ne vois pas laquelle, mais qu'importe, si ça ne résout pas le problème. En suivant l'idée de StormimOn, l'abort du thread est tout de même violent...

[olibara]

Merci Stormimonn

Tu a raison ManualResetEvent rst plus propre que l'abort qu'on avait déja un peu "encadré"

La solution actuelle a été de faire un activate de la form principale dans le show() d'une form Mdi qu'elle affiche

Mais je vais essayer ta proposition

Code amélioration abort :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
   // *************************************************************************************
    public static void Splash()
    {
      Version v = System.Reflection.Assembly.GetExecutingAssembly().GetName().Version;
      frmSplash sf = new frmSplash(v);
      try
      {
        sf.ShowDialog();
      }
      catch (ThreadAbortException)
      {
        sf.Close();
        sf.Dispose();
        sf = null;
      }
    }

[Guulh]

Le plus simple reste quand même de ne pas lancer la fenêtre dans un autre thread. C'est à dire qu'un seul thread, celui de l'UI, se charge de la création et du dessin des contrôles, et que des threads dédiés font le métier, dont le chargement notamment.
Et avec le backgroundworker, rares sont les cas où on a vraiment besoin de toucher au namespace system.threading

[olibara]

Le plus simple reste quand même de ne pas lancer la fenêtre dans un autre thread. C'est à dire qu'un seul thread, celui de l'UI, se charge de la création et du dessin des contrôles, et que des threads dédiés font le métier, dont le chargement notamment.
Et avec le backgroundworker, rares sont les cas où on a vraiment besoin de toucher au namespace system.threading

Le plus academiquement correct .. sans doute
Le plus simple ... je n'en suis pas convaincu

[Guulh]

Le plus academiquement correct .. sans doute
Le plus simple ... je n'en suis pas convaincu

En tant que développeur, le gros de notre travail consiste à trouver un outil dont la puissance est en adéquation avec le besoin, en évitant de tomber d'un côté dans le travers du gros proto mal structuré quand on fait grossir un projet, et de l'autre de l'over-engineering à grands coups de designs patterns quand on a juste à afficher un hello world. Passer d'un niveau de complexité au suivant est une décision difficile, certes

Mais là, pour toute taille de projet, il serait dommage de se passer du backgroundworker, qui fait ce qu'on lui demande simplement, et qui en plus impose de coder à peu près proprement. Ca impose un standard de fait, et je serais bien content dans mes missions ultérieures de le voir en application plutôt que de voir comment un gars s'est encapsulé le namespace System.Threading à sa sauce.