1. Accueil
  2. Visual Basic / VB.NET
  3. Sources Visual Basic / VB.NET
  4. Sources Trucs & Astuces
  5. Détecter une instance précédente de mon application

Détecter une instance précédente de mon application

5/5 (9 avis)

Vue 6 838 fois - Téléchargée 573 fois

Télécharger le projet
Commenter

Description

Beaucoup de questions sur le forum demandent comment gérer efficacement la détection d'une précédente instance d'un même programme.
Voici la solution que j'ai adoptée il y a quelques années et qui me rend bien service.

Dans les toutes premières lignes de code d'une application (dans un Form_Load ou dans une Sub Main), il suffit d'appeler la Sub ActivatePrevInstance fournie dans cette démo pour :
- repérer une forme qui porterait déjà le même nom
- la faire revenir en affichage normal si elle est en icône dans la barre des tâches
- lui donner le focus

Volontairement, cette détection ne teste que les fenêtres dont la classe est du compilé en VB6.
Pour faire la même chose en mode création, App.PrevInstance suffit.

La Sub ActivatePrevInstance peut recevoir en paramètre :
- soit (Me) pour désigner la forme que l'on cherche
- soit le caption de la forme à rechercher
Télécharger le projet

Codes Sources

A voir également

Ajouter un commentaire Commentaires
cs_Jack
Messages postés
14007
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
 80
1 mars 2009 à 21:56
Rohh : la honte
Merci
ghuysmans99
Messages postés
2493
Date d'inscription
jeudi 14 juillet 2005
Statut
Contributeur
Dernière intervention
5 juin 2016
 1
1 mars 2009 à 16:26
"la détextion" : Ce ne serait pas plutôt "la détection" ?
Sinon pour le code 10/10.
cs_Jack
Messages postés
14007
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
 80
9 janv. 2008 à 01:00
Mais de rien, Dok, on est là pour partager !
doktorrelais
Messages postés
4
Date d'inscription
jeudi 22 février 2007
Statut
Membre
Dernière intervention
29 juillet 2013
9 janv. 2008 à 00:24
Ton analyse est parfaite concernant la DB et je suis d'accord avec toi.
En fait, je constate qu'on suit le même raisonnement, car tu distingues
entre le test compilé-compilé et le test création-compilé.
Ce dernier cas, il est vrai que je ne l'utilise pratiquement jamais car
lorsqu'il s'agit de tester des modifications, je pratique par modules
indépendants avant de compiler et le test final a toujours lieu en mode
compilé. Donc, ton approche par recherche de classe est le seul qui
permet le test entre mode création et mode compilé... il se peut que j'ai
un jour besoin de cette fonction et je t'en remercie, bravo.
cs_Jack
Messages postés
14007
Date d'inscription
samedi 29 décembre 2001
Statut
Modérateur
Dernière intervention
28 août 2015
 80
8 janv. 2008 à 15:49
Oui, je suis d'accord sur l'organisation, sauf que, quand un serveur est en écoute sur un port TCP, c'est difficile de tester sans se connecter, mais tu as raison concernant la DB, ça oblige à changer le paramétrage, mais c'est préférable ... sauf si on acquiert des données en mode "test" et qu'on ne veut pas les perdre.
Chaquee application a sa spécificité.

Concernant le code, on s'est mal compris et il n'y a pas raison à polémique :
App.PrevInstance détectera une autre application compilée que si elle même est compilée. Ce test ne fonctionne pas entre une application en mode création et une autre - la même à quelques détails près - compilée.

Je pense qu'un mélange des deux peut être une bonne solution :
PrevInstance : de mode compilé qui surveille mode compilé.
La recherche de classe : de mode création ou mode compilé qui surveille mode compilé.

Vala
Afficher les 9 commentaires
S'inscrire maintenant

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.

Du même auteur (cs_Jack)