Discussion :

[Papy214]

Bonjour

Exit() n'arrête pas mon application sans avoir d'abord laissé tous les messages en cours s'exécuter.

Est-ce que vous connaissez un moyen d'arrêter mon application directement, sans laisser ces messages s'exécuter ? Un genre de Application.Halt() ...

Papy !

[tomlev]

Application.ExitThread

[Papy214]

Application.ExitThread

ça marche pas ....

En fait, mon formulaire principal utilise un assembly qui propose une classe avec un évènement ConnectionLost. L'objet basé sur cette classe est bien créé dans le formulaire principal. Si une procédure de mon objet ne peut se connecter à ma base de données, il déclenche l'évènement, lié à une procédure dans mon formulaire principal. Le code passe bien dans cette procédure mais ensuite, le traitement continue dans l'objet, Le formulaire et l'assembly sont-ils considérés comme 2 threads séparés ?

Code de la classe dans l'assembly:

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
 
public ISession GetSession()
{
	ISession session = null;
	Boolean dontQuit = true;
 
	while (dontQuit && (session == null))
	{
		try
		{
			this.CheckSession();
			session = this.SessionFactory.OpenSession();
		}
		catch (ClassExceptions.DatabaseConnectionLostException)
		{
			session = null;					
		}
 
		if (session == null)
		{
			dontQuit = !Utilities.Dialogs.Confirm(Locale._("Database unavailable!"), Locale._("Quit application?"));
			if (dontQuit)
				this._SessionFactory = null;
			else
				this.OnConnectionLost();
		}
	}
	return session;
}

Code de mon formulaire:

Code :

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

1
2
3
4
5
6
 
void DatabaseConnectionLost(object sender, EventArgs e)
{			
	LockApplication.QuitWithoutMessage = true;
	Application.ExitThread();
}

Je passe bien dans ExitThread à la suite du this.OnConnectionLost(); mais ensuite le programme continue ... dans "return session;"

Hors, je voudrais que ça s'arrête avant !

Papy

[Papy214]

je viens de trouver ce thread ici : http://www.developpez.net/forums/d71...-lapplication/

J'essaye ...


.... ça marche .... impec !

[tomlev]

Le formulaire et l'assembly sont-ils considérés comme 2 threads séparés ?

Pas intrinsèquement, mais il est possible que l'autre assembly crée un autre thread. Si c'est toi qui a créé cet assembly, c'est facile à vérifier

Si l'évènement ConnectionLost est déclenché sur un autre thread, tu peux utiliser Invoke pour effectuer une action sur le thread principal :

Code :

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

1
2
3
4
5
void DatabaseConnectionLost(object sender, EventArgs e)
{			
	LockApplication.QuitWithoutMessage = true;
	this.Invoke(new Action(Application.ExitThread));
}

(*) Le delegate Action n'existe qu'à partir de .NET 3.5, si tu es dans une version antérieure tu peux le déclarer comme ça :

Code :

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

public delegate void Action();

.... ça marche .... impec !

N'oublie pas le bouton alors

Par contre, c'est vraiment crado comme technique... A n'utiliser que si ton appli n'a pas besoin de faire le moindre "nettoyage" avant de quitter.

Et ce code :

Code :

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

1
2
3
4
5
		static void Kill() 
		{
			System.Diagnostics.Process proc = System.Diagnostics.Process.GetProcessById(System.Diagnostics.Process.GetCurrentProcess().Id);
			proc.Kill();
		}

Peut être simplifié en ceci :

Code :

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

1
2
3
4
		static void Kill() 
		{
			System.Diagnostics.Process.GetCurrentProcess().Kill();
		}

[Papy214]

this.Invoke(new Action(Application.ExitThread));

Ben ça marche pas mieux avec ce code. J'ai aussi essayé :

Code :

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

1
2
this.BeginInvoke(new MethodInvoker(delegate() {
Application.ExitThread(); }));

... qui, à mon avis est équivalent, mais rien de mieux. Le code continue son exécution.

Alors, pour le coté "crado", je suis d'accord mais je ne vois pas d'autre solution pour le moment. Pour la procédure coté Assembly, c'est bien bien moi qui l'ai écrite, mais aucun Thread la-dedans. C'est pour ça que je me demandais si le fait d'être dans un assembly plutôt que dans du code directement dans le projet pouvait créer un second Thread que je n'aurais pas vu.

Je me contenterai de ce Kill pour le moment, tout appelant une procédure de nettoyage extraite de mon FormClosing.

Merci tout de même pour le coup de main

[bacelar]

C'est vraiment pas "Clean".

Si vous voulez killer une application, utilisez un programme externe.

Et encore mieux, un débuggeur en ligne, vous aurez au moins le dump de l'application au moment fatidique.

Cela ne vous cachera pas le problème et vous donnera toutes les informations pour corriger le vrai problème de votre application instable.

Comment pouvez-vous fournir une application qui se bloque et y ajouter un mécanisme qui cachera les informations nécessaire à sa correction ?