Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Visual Basic Comment interdire plusieurs lancements de l'exe ?

Comment interdire plusieurs lancements de l'exe ?

7 réponses
Avatar
LE TROLL
Bonjour,

Y a-t-il un moyen d'interdire plusieurs lancements simultanés de l'exe,
sur le principe de l'API FindWindow, comment ?

Merci, cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Bill2
LE TROLL wrote:
Bonjour,

Y a-t-il un moyen d'interdire plusieurs lancements simultanés de
l'exe, sur le principe de l'API FindWindow, comment ?

Merci, cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________



Le moyen le plus simple est d'utiliser ce quie te porpose Visual Studio.
Dans les propriétés du projet, onglet "application", y'a une case
"application à instance unique".
Il te suffit de la cocher.

Sinon, il faut te programmer ton propre système ...
Par exemple en créant un fichier texte dans le rep utilisateur (dans
doc&settings)
Et vérifier quand l'utilisateur lance le prog que le fichier n'existe pas
déjà.

Bon, il faut aussi pense à plusieurs trucs :
- bien effacer le fichier quand l'appli se fermer
- gérer le cas d'un crash appli ou windows, qui fera que le fichier sera tjs
là, alors qu'aucune instance ne tourne ...

--
Bill2
Proverbe à la con : N'oublie jamais un seau et une éponge pour l'avé
Maria
Avatar
LE TROLL
Merci, oui y a le fichier, mais le risque comme tu dis, c'est le crash
(rare), alors une variable d'environnement peut être mieux...

Cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.


"Bill2" a écrit dans le message de
news:
LE TROLL wrote:
Bonjour,

Y a-t-il un moyen d'interdire plusieurs lancements simultanés de
l'exe, sur le principe de l'API FindWindow, comment ?

Merci, cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________



Le moyen le plus simple est d'utiliser ce quie te porpose Visual Studio.
Dans les propriétés du projet, onglet "application", y'a une case
"application à instance unique".
Il te suffit de la cocher.

Sinon, il faut te programmer ton propre système ...
Par exemple en créant un fichier texte dans le rep utilisateur (dans
doc&settings)
Et vérifier quand l'utilisateur lance le prog que le fichier n'existe pas
déjà.

Bon, il faut aussi pense à plusieurs trucs :
- bien effacer le fichier quand l'appli se fermer
- gérer le cas d'un crash appli ou windows, qui fera que le fichier sera
tjs là, alors qu'aucune instance ne tourne ...

--
Bill2
Proverbe à la con : N'oublie jamais un seau et une éponge pour l'avé
Maria



Avatar
Jo
Bonjour,
pour compléter il y a aussi dans les propriétés du projet, onglet
"application", un bouton "Afficher les événements de l'application"
qui affiche:

Namespace My

' Les événements suivants sont disponibles pour MyApplication :
'
' Startup : déclenché au démarrage de l'application avant la création du
formulaire de démarrage.
' Shutdown : déclenché après la fermeture de tous les formulaires de
l'application. Cet événement n'est pas déclenché si l'application se termine
de façon anormale.
' UnhandledException : déclenché si l'application rencontre une
exception non gérée.
' StartupNextInstance : déclenché lors du lancement d'une application à
instance unique et si cette application est déjà active.
' NetworkAvailabilityChanged : déclenché lorsque la connexion réseau est
connectée ou déconnectée.

Partial Friend Class MyApplication
Private Sub MyApplication_Startup(ByVal sender As Object, ByVal e As
Microsoft.VisualBasic.ApplicationServices.StartupEventArgs) Handles
Me.Startup
' déclenché au démarrage de l'application avant la
création du formulaire de démarrage.
end sub
End Class

End Namespace

Cordialement
Jo

"LE TROLL" <le a écrit dans le message de groupe de
discussion : #
Merci, oui y a le fichier, mais le risque comme tu dis, c'est le crash
(rare), alors une variable d'environnement peut être mieux...

Cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.


"Bill2" a écrit dans le message de
news:
LE TROLL wrote:
Bonjour,

Y a-t-il un moyen d'interdire plusieurs lancements simultanés de
l'exe, sur le principe de l'API FindWindow, comment ?

Merci, cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________



Le moyen le plus simple est d'utiliser ce quie te porpose Visual Studio.
Dans les propriétés du projet, onglet "application", y'a une case
"application à instance unique".
Il te suffit de la cocher.

Sinon, il faut te programmer ton propre système ...
Par exemple en créant un fichier texte dans le rep utilisateur (dans
doc&settings)
Et vérifier quand l'utilisateur lance le prog que le fichier n'existe pas
déjà.

Bon, il faut aussi pense à plusieurs trucs :
- bien effacer le fichier quand l'appli se fermer
- gérer le cas d'un crash appli ou windows, qui fera que le fichier sera
tjs là, alors qu'aucune instance ne tourne ...

--
Bill2
Proverbe à la con : N'oublie jamais un seau et une éponge pour l'avé
Maria






Avatar
Gloops
Bonjour,

LE TROLL a écrit, le 09/10/2009 14:52 :
alors une variable d'environnement peut être mieux...



Comme on n'oublie pas que chaque programme tourne avec sa copie de
l'environnement, il faut déterminer quelle copie doit être modifiée ,
peut-être celle de l'appelant (sous réserve d'avoir les droits), auqu el
cas on en revient au même problème qu'avec le fichier en cas de plant age
-avec, en moins, l'avantage de la simplicité, parce que l'environnement
de l'appelant, il faut quand même aller le chercher.

Ah, peut-être l'idée du FindWindow n'était-elle pas si mauvaise apr ès
tout. Bien penser à donner à sa fenêtre un titre ou un nom de class e
suffisamment spécifique. Pour le titre c'est fastoche, pour le nom de
classe il faudrait que je fasse une petite révision ...

Ou alors, on met l'utilisateur au parfum, et en cas de plantage on lui
dit d'aller effacer tel fichier. C'est ce qui se passe avec Access où o n
est invité (plus ou moins explicitement) à effacer le fichier ldb ave c
le même nom que la base, si sa non-disparition est liée à un planta ge
d'Access.

Il peut y avoir besoin de creuser la question de savoir dans quels cas
on peut ouvrir l'application plusieurs fois (par exemple à partir de
postes différents) et ce qui doit se passer si l'une des occurrences se
plante.
Avatar
Bill2
Gloops wrote:
Bonjour,

LE TROLL a écrit, le 09/10/2009 14:52 :
alors une variable d'environnement peut être mieux...



Comme on n'oublie pas que chaque programme tourne avec sa copie de
l'environnement, il faut déterminer quelle copie doit être modifiée,
peut-être celle de l'appelant (sous réserve d'avoir les droits),
auquel cas on en revient au même problème qu'avec le fichier en cas
de plantage -avec, en moins, l'avantage de la simplicité, parce que
l'environnement de l'appelant, il faut quand même aller le chercher.

Ah, peut-être l'idée du FindWindow n'était-elle pas si mauvaise après
tout. Bien penser à donner à sa fenêtre un titre ou un nom de classe
suffisamment spécifique. Pour le titre c'est fastoche, pour le nom de
classe il faudrait que je fasse une petite révision ...

Ou alors, on met l'utilisateur au parfum, et en cas de plantage on lui
dit d'aller effacer tel fichier. C'est ce qui se passe avec Access où
on est invité (plus ou moins explicitement) à effacer le fichier ldb
avec le même nom que la base, si sa non-disparition est liée à un
plantage d'Access.

Il peut y avoir besoin de creuser la question de savoir dans quels cas
on peut ouvrir l'application plusieurs fois (par exemple à partir de
postes différents) et ce qui doit se passer si l'une des occurrences
se plante.



C'est avec un fichier que je gère les instances uniques de mon soft.
Avec les vars d'environnement, on obtiens facilement le rep de stockage du
user, et donc pour chaque user, on peut avoir un fichier différent.

Donc sur un meme ordi, chaque user loggué peut lancer "sa" copie du prog.
(pareil : la conf de chacun est stockée dans le rep user)

Et dans mon fichier texte, je rajoute le Pid du process.
Comme ça, gestion complète en cas de plantage :
- si pas de fichier, aucun pb
- si fichier, alors je regarde le PID :
si le process correspondand à PID n'existe pas, alors c'est que je peux
lancer ma copie du prog
si le process correspondant à PID existe ET que le nom d'exe est le
même, alors c'est que j'ai déjà lancé ma copie, et là j'envoie un message
d'erreur


--
Bill2
Utilisez Process Manager, gestionnaire de processus automatique :
http://www.bill2-software.com/processmanager/
Avatar
LE TROLL
merci

--
Cordialement ;o)
-
Logiciels, romans, contacts : http://irolog.free.fr
_______________________
.
.


"Gloops" a écrit dans le message de
news:
Bonjour,

LE TROLL a écrit, le 09/10/2009 14:52 :
alors une variable d'environnement peut être mieux...



Comme on n'oublie pas que chaque programme tourne avec sa copie de
l'environnement, il faut déterminer quelle copie doit être modifiée,
peut-être celle de l'appelant (sous réserve d'avoir les droits), auquel
cas on en revient au même problème qu'avec le fichier en cas de plantage
-avec, en moins, l'avantage de la simplicité, parce que l'environnement
de l'appelant, il faut quand même aller le chercher.

Ah, peut-être l'idée du FindWindow n'était-elle pas si mauvaise après
tout. Bien penser à donner à sa fenêtre un titre ou un nom de classe
suffisamment spécifique. Pour le titre c'est fastoche, pour le nom de
classe il faudrait que je fasse une petite révision ...

Ou alors, on met l'utilisateur au parfum, et en cas de plantage on lui
dit d'aller effacer tel fichier. C'est ce qui se passe avec Access où on
est invité (plus ou moins explicitement) à effacer le fichier ldb avec
le même nom que la base, si sa non-disparition est liée à un plantage
d'Access.

Il peut y avoir besoin de creuser la question de savoir dans quels cas
on peut ouvrir l'application plusieurs fois (par exemple à partir de
postes différents) et ce qui doit se passer si l'une des occurrences se
plante.
Avatar
Gloops
Bonjour,

Bill2 a écrit, le 09/10/2009 20:41 :
C'est avec un fichier que je gère les instances uniques de mon soft.
Avec les vars d'environnement, on obtiens facilement le rep de stockage du
user, et donc pour chaque user, on peut avoir un fichier différent.



Effectivement, on trouve USERPROFILE et HOMEPATH, qui donnent le
répertoire principal de l'utilisateur (où se trouvent "Mes Documents" ,
"Local Settings" ...)

A part ça il existe l'énumération
Microsoft.VisualBasic.FileIO.SpecialDirectories et sa valeur
MyDocuments, avec probablement l'avantage sur les variables
d'environnement d'offrir une meilleure portabilité entre versions de
Windows.

A supposer que ça ne suffise pas il y a aussi une API,

[DllImport("shell32.dll", EntryPoint="SHGetSpecialFolderPathA")]
private static extern int SHGetSpecialFolderPath (int hwnd, string
pszPath, int csidl, int fCreate);