Sub Command4_Click() ' calendrier
Dim x
If App.PrevInstance Then Exit Sub
If Form1.eval = False Then x = Shell("calendrier.exe ", 1)
A quoi lie-t-on App.PrevInstance pour qu'il soit opérationnel ???
--
Merci beaucoup, au revoir et à bientôt :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
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
LE TROLL
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
-- Merci beaucoup, au revoir et à bientôt :o) ------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "LE TROLL" <le a écrit dans le message de news: %23EqGc$ | Bonjour, | | Je fais un truc qui ne fonctionne pas : | | Sub Command4_Click() ' calendrier | Dim x | If App.PrevInstance Then Exit Sub | If Form1.eval = False Then x = Shell("calendrier.exe ", 1) | | A quoi lie-t-on App.PrevInstance pour qu'il soit opérationnel ??? | | -- | Merci beaucoup, au revoir et à bientôt :o) | ------ | Romans, logiciels, email, site personnel | http://irolog.free.fr/joe.htm | ------------------------------------------------------------------------------------ | |
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
--
Merci beaucoup, au revoir et à bientôt :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"LE TROLL" <le troll@enfer.fr> a écrit dans le message de news:
%23EqGc$MEJHA.1272@TK2MSFTNGP02.phx.gbl...
| Bonjour,
|
| Je fais un truc qui ne fonctionne pas :
|
| Sub Command4_Click() ' calendrier
| Dim x
| If App.PrevInstance Then Exit Sub
| If Form1.eval = False Then x = Shell("calendrier.exe ", 1)
|
| A quoi lie-t-on App.PrevInstance pour qu'il soit opérationnel ???
|
| --
| Merci beaucoup, au revoir et à bientôt :o)
| ------
| Romans, logiciels, email, site personnel
| http://irolog.free.fr/joe.htm
| ------------------------------------------------------------------------------------
|
|
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
-- Merci beaucoup, au revoir et à bientôt :o) ------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "LE TROLL" <le a écrit dans le message de news: %23EqGc$ | Bonjour, | | Je fais un truc qui ne fonctionne pas : | | Sub Command4_Click() ' calendrier | Dim x | If App.PrevInstance Then Exit Sub | If Form1.eval = False Then x = Shell("calendrier.exe ", 1) | | A quoi lie-t-on App.PrevInstance pour qu'il soit opérationnel ??? | | -- | Merci beaucoup, au revoir et à bientôt :o) | ------ | Romans, logiciels, email, site personnel | http://irolog.free.fr/joe.htm | ------------------------------------------------------------------------------------ | |
Jean-marc
LE TROLL wrote:
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
Hello,
A toutes fins utiles,je signale la présence dans la FAQ d'un article expliquant tout cela, ainsi que l'existence de moyens alternatifs à mettre en oeuvre an fonction des besoins:
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
Hello,
A toutes fins utiles,je signale la présence dans la FAQ d'un article
expliquant tout cela, ainsi que l'existence de moyens alternatifs
à mettre en oeuvre an fonction des besoins:
RESOLU, j'ai trouvé, faut mettre dans l'appelé :o)
Hello,
A toutes fins utiles,je signale la présence dans la FAQ d'un article expliquant tout cela, ainsi que l'existence de moyens alternatifs à mettre en oeuvre an fonction des besoins:
A toutes fins utiles,je signale la présence dans la FAQ d'un article expliquant tout cela, ainsi que l'existence de moyens alternatifs à mettre en oeuvre an fonction des besoins:
http://faq.vb.free.fr/index.php?questionF
Salut,
J'ai consulté ton lien, perso pour le pevInstance j'utilise CreateFileMapping pour créer un fichier mappé en mémoire, avec le nom de l'appli! pas le chemin! ainsi si l'exe est exécuté depuis un autre endroit je le détecte sans problèmes. De plus la mise en place est beaucoup plus aisée et on peut y mettre des tonnes de données de "sessions en cours"
A toutes fins utiles,je signale la présence dans la FAQ d'un article
expliquant tout cela, ainsi que l'existence de moyens alternatifs
à mettre en oeuvre an fonction des besoins:
http://faq.vb.free.fr/index.php?questionF
Salut,
J'ai consulté ton lien, perso pour le pevInstance j'utilise
CreateFileMapping
pour créer un fichier mappé en mémoire, avec le nom de l'appli! pas le
chemin!
ainsi si l'exe est exécuté depuis un autre endroit je le détecte sans
problèmes.
De plus la mise en place est beaucoup plus aisée et on peut y mettre des
tonnes de données de "sessions en cours"
A toutes fins utiles,je signale la présence dans la FAQ d'un article expliquant tout cela, ainsi que l'existence de moyens alternatifs à mettre en oeuvre an fonction des besoins:
http://faq.vb.free.fr/index.php?questionF
Salut,
J'ai consulté ton lien, perso pour le pevInstance j'utilise CreateFileMapping pour créer un fichier mappé en mémoire, avec le nom de l'appli! pas le chemin! ainsi si l'exe est exécuté depuis un autre endroit je le détecte sans problèmes. De plus la mise en place est beaucoup plus aisée et on peut y mettre des tonnes de données de "sessions en cours"
oup's lu et ecris trop vite... pour le chemin je voulais dire le nom, dans ton exemple de mutex si l'utilisateur change le nom de ton exe tu n'y vois que du feu...
++
oup's lu et ecris trop vite...
pour le chemin je voulais dire le nom, dans ton exemple de mutex si
l'utilisateur change le nom de ton exe tu n'y vois que du feu...
oup's lu et ecris trop vite... pour le chemin je voulais dire le nom, dans ton exemple de mutex si l'utilisateur change le nom de ton exe tu n'y vois que du feu...
++
jean-marc
"Sebastien" wrote in message news:
oup's lu et ecris trop vite...
Hello,
pour le chemin je voulais dire le nom, dans ton exemple de mutex si l'utilisateur change le nom de ton exe tu n'y vois que du feu...
Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms différents à partir de l'exe original, on va effectivement tromper le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode permettant d'éviter ce genre de "hacking".
On parle ici d'usage normal.
Ceci dit, si on veut une garantie d'unicité, il suffit de créer le mutex en utilisant en lieu et place du nom de l'exe un GUID, par exemple.
Ceci n'enlève rien au mérite de l'emploi du fileMapping :-)
"Sebastien" <Sebastien.groulard@gmail.com> wrote in message
news:D596E4D6-AC37-48AD-8CEA-EDE265AFFA7C@microsoft.com...
oup's lu et ecris trop vite...
Hello,
pour le chemin je voulais dire le nom, dans ton exemple de mutex si
l'utilisateur change le nom de ton exe tu n'y vois que du feu...
Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms
différents à partir de l'exe original, on va effectivement tromper
le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode
permettant d'éviter ce genre de "hacking".
On parle ici d'usage normal.
Ceci dit, si on veut une garantie d'unicité, il suffit de créer
le mutex en utilisant en lieu et place du nom de l'exe un GUID,
par exemple.
Ceci n'enlève rien au mérite de l'emploi du fileMapping :-)
pour le chemin je voulais dire le nom, dans ton exemple de mutex si l'utilisateur change le nom de ton exe tu n'y vois que du feu...
Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms différents à partir de l'exe original, on va effectivement tromper le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode permettant d'éviter ce genre de "hacking".
On parle ici d'usage normal.
Ceci dit, si on veut une garantie d'unicité, il suffit de créer le mutex en utilisant en lieu et place du nom de l'exe un GUID, par exemple.
Ceci n'enlève rien au mérite de l'emploi du fileMapping :-)
>Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms différents à partir de l'exe original, on va effectivement tromper le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode permettant d'éviter ce genre de "hacking".
Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine" par l'utilisateur...
Si on veut gerer le nombre d'instance, il y a souvent une bonne raison donc je trouve ca un peu dommage de ne pas prendre en compte un eventuel renomage...
Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit de mettre le nom de l'appli en "dur" et le tour est joué
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est pas le mutex c'est le app.exename...
++
>Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms
différents à partir de l'exe original, on va effectivement tromper
le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode
permettant d'éviter ce genre de "hacking".
Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine"
par l'utilisateur...
Si on veut gerer le nombre d'instance, il y a souvent une bonne raison donc
je trouve ca un peu dommage de ne pas prendre en compte un eventuel
renomage...
Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit
de mettre le nom de l'appli en "dur" et le tour est joué
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est
pas le mutex c'est le app.exename...
>Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms différents à partir de l'exe original, on va effectivement tromper le mutex et on pourra lancer 2 fois. C'est un fait.
Mais ce n'est pas le but de l'article de présenter une méthode permettant d'éviter ce genre de "hacking".
Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine" par l'utilisateur...
Si on veut gerer le nombre d'instance, il y a souvent une bonne raison donc je trouve ca un peu dommage de ne pas prendre en compte un eventuel renomage...
Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit de mettre le nom de l'appli en "dur" et le tour est joué
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est pas le mutex c'est le app.exename...
++
jean-marc
"Sebastien" wrote in message news:
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est pas le mutex c'est le app.exename...
Je pense que tu as raison sur le fond. Lors de la prochaine release de la FAQ, nous mettrons à jour l'article pour signaler ça et indiquer une alternative possible (nom en dur ou GUID, ce dernier étant plus safe car on a alors une garantie d'unicité).
Merci en tout cas du feedback, qui nous aide à améliorer la qualité de notre FAQ.
"Sebastien" <Sebastien.groulard@gmail.com> wrote in message
news:1089D57B-E81C-47C2-BA18-49117AC1A551@microsoft.com...
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene
c'est pas le mutex c'est le app.exename...
Je pense que tu as raison sur le fond. Lors de la prochaine
release de la FAQ, nous mettrons à jour l'article pour signaler
ça et indiquer une alternative possible (nom en dur ou GUID, ce
dernier étant plus safe car on a alors une garantie d'unicité).
Merci en tout cas du feedback, qui nous aide à améliorer
la qualité de notre FAQ.
Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est pas le mutex c'est le app.exename...
Je pense que tu as raison sur le fond. Lors de la prochaine release de la FAQ, nous mettrons à jour l'article pour signaler ça et indiquer une alternative possible (nom en dur ou GUID, ce dernier étant plus safe car on a alors une garantie d'unicité).
Merci en tout cas du feedback, qui nous aide à améliorer la qualité de notre FAQ.
Me concernant (auteur de la question), un logiciel est livré, après si l'utilisateur en fait une tondeuse à gazon, ce n'est plus le problème de l'auteur, pas pareil qu'en entreprise donc...
Et pour app.PrevInstance, ben en fait ce n'était pas suffisant, car, ouvrant le programme avec le groupe d'API qui permettent aussi de fermer le programme ouvert (je n'ai plus le nom en tête), ben si jamais avec le bouton on tentait d'ouvrir plusieurs fois le programme, bien qu'ouvert une seule fois grâce à PrevInstance, néanmoins l'API n'arrivait plus à fermer le programme qu'elle avait ouvert. Comme quoi, même avec PrevInstance, ça doit laisser des traces quelques part de tenter plusieurs ouvertures, ou perturber... Alors j'ai eu sa peau par la méthode agricole, laissant le PrevInstance de l'appelé, dans l'appelant je lui ai mis un bouton qui fait alternat, de facto, le programme ne peut être sollicité qu'une fois... Et là, le groupe d'API le ferme bien :o)
------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Sebastien" a écrit dans le message de news:
| >Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms | >différents à partir de l'exe original, on va effectivement tromper | >le mutex et on pourra lancer 2 fois. C'est un fait. | | >Mais ce n'est pas le but de l'article de présenter une méthode | >permettant d'éviter ce genre de "hacking". | | Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine" | par l'utilisateur... | | Si on veut gerer le nombre d'instance, il y a souvent une bonne raison donc | je trouve ca un peu dommage de ne pas prendre en compte un eventuel | renomage... | | Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit | de mettre le nom de l'appli en "dur" et le tour est joué | | Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est | pas le mutex c'est le app.exename... | | ++ |
Me concernant (auteur de la question), un logiciel est livré, après si
l'utilisateur en fait une tondeuse à gazon, ce n'est plus le problème de
l'auteur, pas pareil qu'en entreprise donc...
Et pour app.PrevInstance, ben en fait ce n'était pas suffisant, car, ouvrant
le programme avec le groupe d'API qui permettent aussi de fermer le
programme ouvert (je n'ai plus le nom en tête), ben si jamais avec le bouton
on tentait d'ouvrir plusieurs fois le programme, bien qu'ouvert une seule
fois grâce à PrevInstance, néanmoins l'API n'arrivait plus à fermer le
programme qu'elle avait ouvert. Comme quoi, même avec PrevInstance, ça doit
laisser des traces quelques part de tenter plusieurs ouvertures, ou
perturber...
Alors j'ai eu sa peau par la méthode agricole, laissant le PrevInstance de
l'appelé, dans l'appelant je lui ai mis un bouton qui fait alternat, de
facto, le programme ne peut être sollicité qu'une fois... Et là, le groupe
d'API le ferme bien :o)
------
Romans, logiciels, email, site personnel
http://irolog.free.fr/joe.htm
------------------------------------------------------------------------------------
"Sebastien" <Sebastien.groulard@gmail.com> a écrit dans le message de news:
1089D57B-E81C-47C2-BA18-49117AC1A551@microsoft.com...
| >Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms
| >différents à partir de l'exe original, on va effectivement tromper
| >le mutex et on pourra lancer 2 fois. C'est un fait.
|
| >Mais ce n'est pas le but de l'article de présenter une méthode
| >permettant d'éviter ce genre de "hacking".
|
| Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine"
| par l'utilisateur...
|
| Si on veut gerer le nombre d'instance, il y a souvent une bonne raison
donc
| je trouve ca un peu dommage de ne pas prendre en compte un eventuel
| renomage...
|
| Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit
| de mettre le nom de l'appli en "dur" et le tour est joué
|
| Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene
c'est
| pas le mutex c'est le app.exename...
|
| ++
|
Me concernant (auteur de la question), un logiciel est livré, après si l'utilisateur en fait une tondeuse à gazon, ce n'est plus le problème de l'auteur, pas pareil qu'en entreprise donc...
Et pour app.PrevInstance, ben en fait ce n'était pas suffisant, car, ouvrant le programme avec le groupe d'API qui permettent aussi de fermer le programme ouvert (je n'ai plus le nom en tête), ben si jamais avec le bouton on tentait d'ouvrir plusieurs fois le programme, bien qu'ouvert une seule fois grâce à PrevInstance, néanmoins l'API n'arrivait plus à fermer le programme qu'elle avait ouvert. Comme quoi, même avec PrevInstance, ça doit laisser des traces quelques part de tenter plusieurs ouvertures, ou perturber... Alors j'ai eu sa peau par la méthode agricole, laissant le PrevInstance de l'appelé, dans l'appelant je lui ai mis un bouton qui fait alternat, de facto, le programme ne peut être sollicité qu'une fois... Et là, le groupe d'API le ferme bien :o)
------ Romans, logiciels, email, site personnel http://irolog.free.fr/joe.htm ------------------------------------------------------------------------------------ "Sebastien" a écrit dans le message de news:
| >Oui et non. Techniquement, oui bien sur. Si on crée 2 exe avec 2 noms | >différents à partir de l'exe original, on va effectivement tromper | >le mutex et on pourra lancer 2 fois. C'est un fait. | | >Mais ce n'est pas le but de l'article de présenter une méthode | >permettant d'éviter ce genre de "hacking". | | Eh bah je parlais pas de "haking" ceci peut etre fait de maniere "anodine" | par l'utilisateur... | | Si on veut gerer le nombre d'instance, il y a souvent une bonne raison donc | je trouve ca un peu dommage de ne pas prendre en compte un eventuel | renomage... | | Je ne parle pas du debat FileMapping ou mutex car dans les 2 cas il suffit | de mettre le nom de l'appli en "dur" et le tour est joué | | Je prefere le FileMapping pour des tas de raisons, mais ce qui me gene c'est | pas le mutex c'est le app.exename... | | ++ |
