Comment interdire plusieurs lancements de l'exe ?

Le
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
_______________________
.
.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Bill2
Le #20321221
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
LE TROLL
Le #20321321
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" 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



Jo
Le #20322111
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" 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" 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






Gloops
Le #20323711
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.
Bill2
Le #20323701
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/
LE TROLL
Le #20324121
merci

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


"Gloops" 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.
Gloops
Le #20324101
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);
Publicité
Poster une réponse
Anonyme