J'ai une application MonAppli.exe, qui, une fois lancée, se met en attente
de messages (en fait, scanne périodiquement des files Websphere MQ, mais
c'est accessoire dans mon problème).
Je souhaite pouvoir arrêter cette appli par une ligne de commande, pour
gérer le tout sous forme de tâches planifiées. L'appli ne doit pas être
arrêtée 'brutalement", car elle a pas mal de 'nettoyage' à faire avant de
finir.
Pour des raisons particulières, je ne peux pas créer un service Windows.
J'ai bien pensé à une solution à base de MUTEX, mais cela me semble un peu
complexe ... (l'appli de paramètre STOP prend un MUTEX nommé, et si l'appli
de paramètre START qui essaye périodiquement de le prendre n'y parvient pas,
alors elle s'arrête).
Des idées ?
--
Cordialement
Oxiane
----------------------------------------------------------
Omnia vanitas
Pour des raisons particulières, je ne peux pas créer un service Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non un mutex. Une instance démarrée avec START, met en place un thread qui attend sur un event particulier, créé par elle. L'instance démarrée avec STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event libère le thread dans l'instance démarrée avec START et celui-ci fait ce qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si les 2 instances peuvent éventuellement tourner dans 2 sessions différentes (comme sous XP Familial ou XP Pro avec le FUS activé).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Pour des raisons particulières, je ne peux pas créer un service
Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une
instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque
entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non
un mutex. Une instance démarrée avec START, met en place un thread qui
attend sur un event particulier, créé par elle. L'instance démarrée avec
STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event
libère le thread dans l'instance démarrée avec START et celui-ci fait ce
qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si les
2 instances peuvent éventuellement tourner dans 2 sessions différentes
(comme sous XP Familial ou XP Pro avec le FUS activé).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Pour des raisons particulières, je ne peux pas créer un service Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non un mutex. Une instance démarrée avec START, met en place un thread qui attend sur un event particulier, créé par elle. L'instance démarrée avec STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event libère le thread dans l'instance démarrée avec START et celui-ci fait ce qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si les 2 instances peuvent éventuellement tourner dans 2 sessions différentes (comme sous XP Familial ou XP Pro avec le FUS activé).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Timur
Merci Patrick.
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
En effet, mais à force de cliquer sur le bouton "START" de windows pour accéder à l'arrêt de mon ordinateur, je prends de mauvaises habitudes .... ;-))))
IPC, event nommé ... Ca sent le code non managé, non ?
L'idée est-elle de créer un évènement de portée 'système' (je m'exprime peut-être mal), qui est lancé par un process et attrapé par un autre ?
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
Bonjour,
> Idéalement : > > MonAppli.exe START --> lance l'appli > MonAppli.exe STOP --> Arrête l'appli > > Pour des raisons particulières, je ne peux pas créer un service > Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non un mutex. Une instance démarrée avec START, met en place un thread qui attend sur un event particulier, créé par elle. L'instance démarrée avec STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event libère le thread dans l'instance démarrée avec START et celui-ci fait ce qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si
les
2 instances peuvent éventuellement tourner dans 2 sessions différentes (comme sous XP Familial ou XP Pro avec le FUS activé).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Merci Patrick.
C'est une approche un peu particulière que de vouloir, pour arrêter une
instance d'une application, en lancer une deuxième :-) .
En effet, mais à force de cliquer sur le bouton "START" de windows pour
accéder à l'arrêt de mon ordinateur, je prends de mauvaises habitudes ....
;-))))
IPC, event nommé ... Ca sent le code non managé, non ?
L'idée est-elle de créer un évènement de portée 'système' (je m'exprime
peut-être mal), qui est lancé par un process et attrapé par un autre ?
Oxiane
----------------------------------------------------------
Omnia vanitas
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:eF2TBHbpGHA.3584@TK2MSFTNGP03.phx.gbl...
Bonjour,
> Idéalement :
>
> MonAppli.exe START --> lance l'appli
> MonAppli.exe STOP --> Arrête l'appli
>
> Pour des raisons particulières, je ne peux pas créer un service
> Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une
instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque
entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non
un mutex. Une instance démarrée avec START, met en place un thread qui
attend sur un event particulier, créé par elle. L'instance démarrée avec
STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event
libère le thread dans l'instance démarrée avec START et celui-ci fait ce
qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si
les
2 instances peuvent éventuellement tourner dans 2 sessions différentes
(comme sous XP Familial ou XP Pro avec le FUS activé).
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
En effet, mais à force de cliquer sur le bouton "START" de windows pour accéder à l'arrêt de mon ordinateur, je prends de mauvaises habitudes .... ;-))))
IPC, event nommé ... Ca sent le code non managé, non ?
L'idée est-elle de créer un évènement de portée 'système' (je m'exprime peut-être mal), qui est lancé par un process et attrapé par un autre ?
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
Bonjour,
> Idéalement : > > MonAppli.exe START --> lance l'appli > MonAppli.exe STOP --> Arrête l'appli > > Pour des raisons particulières, je ne peux pas créer un service > Windows.
C'est une approche un peu particulière que de vouloir, pour arrêter une instance d'une application, en lancer une deuxième :-) .
Il faut de toute évidence mettre en place un mécanisme d'IPC quelconque entre les 2 applis. Le plus simple serait d'utiliser un event nommé et non un mutex. Une instance démarrée avec START, met en place un thread qui attend sur un event particulier, créé par elle. L'instance démarrée avec STOP ouvre et déclenche cet event nommé et se termine elle-même. L'event libère le thread dans l'instance démarrée avec START et celui-ci fait ce qu'il faut pour terminer l'appli correctement.
L'event nommé en question doit se trouver dans le namespace "Global" si
les
2 instances peuvent éventuellement tourner dans 2 sessions différentes (comme sous XP Familial ou XP Pro avec le FUS activé).
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de type Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en mode non managé mais on est déjà "très près du métal". Pas de souci.
L'idée est-elle de créer un évènement de portée 'système' (je m'exprime peut-être mal), qui est lancé par un process et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que les 2 instances tourneront toujours dans la même session.
mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le
kernel qui gère ces objets et il faut bien à un moment donné passer en mode
non managé mais on est déjà "très près du métal". Pas de souci.
L'idée est-elle de créer un évènement de portée 'système'
(je m'exprime peut-être mal), qui est lancé par un process
et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom
de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que les
2 instances tourneront toujours dans la même session.
mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce
cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting
pour régler ce problème :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de type Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en mode non managé mais on est déjà "très près du métal". Pas de souci.
L'idée est-elle de créer un évènement de portée 'système' (je m'exprime peut-être mal), qui est lancé par un process et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que les 2 instances tourneront toujours dans la même session.
mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Timur
Merci pour ces précisions.
En suivant vos pistes, j'ai trouvé http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système' > (je m'exprime peut-être mal), qui est lancé par un process > et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Merci pour ces précisions.
En suivant vos pistes, j'ai trouvé
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des
solutions, mais aussi à donner des explications. On sent l'expérience de
formateur .... ( on s'est déjà croisés chez LTI ! )
--
Cordialement
Oxiane
----------------------------------------------------------
Omnia vanitas
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:ebMZikcpGHA.3324@TK2MSFTNGP05.phx.gbl...
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le
kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système'
> (je m'exprime peut-être mal), qui est lancé par un process
> et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom
de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce
cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting
pour régler ce problème :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
En suivant vos pistes, j'ai trouvé http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système' > (je m'exprime peut-être mal), qui est lancé par un process > et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
Timur wrote:
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Timur wrote:
Encore merci de passer autant de temps, non seulement à trouver des
solutions, mais aussi à donner des explications. On sent l'expérience
de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrice
Ou peut-être détecter l'instance précédente au lancement et appeler la méthode permettant d'y mettre fin ?
-- Patrice
"Timur" a écrit dans le message de news:
Merci pour ces précisions.
En suivant vos pistes, j'ai trouvé http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système' > (je m'exprime peut-être mal), qui est lancé par un process > et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Ou peut-être détecter l'instance précédente au lancement et appeler la
méthode permettant d'y mettre fin ?
--
Patrice
"Timur" <fgregoire@enlever_ceci.freesurf.frzzz> a écrit dans le message de
news: uUJTBxcpGHA.3820@TK2MSFTNGP05.phx.gbl...
Merci pour ces précisions.
En suivant vos pistes, j'ai trouvé
http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des
solutions, mais aussi à donner des explications. On sent l'expérience de
formateur .... ( on s'est déjà croisés chez LTI ! )
--
Cordialement
Oxiane
----------------------------------------------------------
Omnia vanitas
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:ebMZikcpGHA.3324@TK2MSFTNGP05.phx.gbl...
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le
kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système'
> (je m'exprime peut-être mal), qui est lancé par un process
> et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le
nom
de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans
ce
cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net
Remoting
pour régler ce problème :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Ou peut-être détecter l'instance précédente au lancement et appeler la méthode permettant d'y mettre fin ?
-- Patrice
"Timur" a écrit dans le message de news:
Merci pour ces précisions.
En suivant vos pistes, j'ai trouvé http://groups.google.com/group/microsoft.public.dotnet.languages.csharp/browse_thread/thread/907fe63eb18004e8/f71dc6adb0450aeb?lnk=st&q=%22named+events%22+c%23+win32&rnum=2#f71dc6adb0450aeb
qui va m'aider je pense.
Encore merci de passer autant de temps, non seulement à trouver des solutions, mais aussi à donner des explications. On sent l'expérience de formateur .... ( on s'est déjà croisés chez LTI ! )
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
> IPC, event nommé ... Ca sent le code non managé, non ?
IPC est un terme générique qui n'est pas lié au mode managé ou non.
Il y a des classes natives .Net qui supportent les objets de synchro de
type
Event (Threading.EventWaitHandle). Au bout du compte, c'est quand même le kernel qui gère ces objets et il faut bien à un moment donné passer en
mode
non managé mais on est déjà "très près du métal". Pas de souci.
> L'idée est-elle de créer un évènement de portée 'système' > (je m'exprime peut-être mal), qui est lancé par un process > et attrapé par un autre ?
Oui. "Portée système" = "namespace Global" comme précisé plus haut. Le nom de l'objet event doit être "Globalxxxxx" à moins que vous soyez sûr que
les
2 instances tourneront toujours dans la même session.
> mais cela me semble un peu compliqué...
Utiliser un event est probablement la méthode d'IPC la plus simple dans ce cas. On ne va quand même pas utiliser un MMF, des sockets ou .Net Remoting pour régler ce problème :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
Bonjour,
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code dans un processus depuis un autre processus sans passer par un mécanisme d'IPC ou de RPC quelconque (socket, COM, DCOM ou .Net remoting par exemple) . En tous cas, pas depuis que l'on a abandonné le monde du 16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire avec l'API GetInstanceData. Mais cela était basé sur le fait que tous les processus tournaient dans le même espace adresse. Cette incongruité n'a bien heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process id depuis la deuxième instance mais il est question ici de faire une sortie "propre" comme cela a été précisé plus haut :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Bonjour,
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code dans
un processus depuis un autre processus sans passer par un mécanisme d'IPC ou
de RPC quelconque (socket, COM, DCOM ou .Net remoting par exemple) . En tous
cas, pas depuis que l'on a abandonné le monde du 16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire avec
l'API GetInstanceData. Mais cela était basé sur le fait que tous les
processus tournaient dans le même espace adresse. Cette incongruité n'a bien
heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process id
depuis la deuxième instance mais il est question ici de faire une sortie
"propre" comme cela a été précisé plus haut :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code dans un processus depuis un autre processus sans passer par un mécanisme d'IPC ou de RPC quelconque (socket, COM, DCOM ou .Net remoting par exemple) . En tous cas, pas depuis que l'on a abandonné le monde du 16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire avec l'API GetInstanceData. Mais cela était basé sur le fait que tous les processus tournaient dans le même espace adresse. Cette incongruité n'a bien heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process id depuis la deuxième instance mais il est question ici de faire une sortie "propre" comme cela a été précisé plus haut :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Timur
> :-) Ah oui? Quel cours?
La liste commence à être longue !
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment Design Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
Timur wrote: > Encore merci de passer autant de temps, non seulement à trouver des > solutions, mais aussi à donner des explications. On sent l'expérience > de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
> :-) Ah oui? Quel cours?
La liste commence à être longue !
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment Design
Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
--
Cordialement
Oxiane
----------------------------------------------------------
Omnia vanitas
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news:eMikk2cpGHA.4368@TK2MSFTNGP05.phx.gbl...
Timur wrote:
> Encore merci de passer autant de temps, non seulement à trouver des
> solutions, mais aussi à donner des explications. On sent l'expérience
> de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment Design Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
-- Cordialement
Oxiane ---------------------------------------------------------- Omnia vanitas
"Patrick Philippot" a écrit dans le message de news:
Timur wrote: > Encore merci de passer autant de temps, non seulement à trouver des > solutions, mais aussi à donner des explications. On sent l'expérience > de formateur .... ( on s'est déjà croisés chez LTI ! )
:-) Ah oui? Quel cours?
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
Timur wrote:
:-) Ah oui? Quel cours?
La liste commence à être longue !
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment Design Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
Il fallait le dire tout de suite... :-)))
Bonne journée.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Timur wrote:
:-) Ah oui? Quel cours?
La liste commence à être longue !
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment
Design Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
Il fallait le dire tout de suite... :-)))
Bonne journée.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
VB6 - Active X, et aussi le 503 VB. NET , et aussi très récemment Design Patern, et .... DESUI Nanterre 2001-2002 !
Vous me remettez ?
Il fallait le dire tout de suite... :-)))
Bonne journée.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrice
Je pensais plutôt effectivement à quelque chose comme .NET remoting ce qui pourrait être plus général et permettre d'ajouter facilement toute autre fonction exposée (un peu comme le ngen.exe qui permet maintenant d'interagir avec le service Windows correspondant...).
-- Patrice
"Patrick Philippot" a écrit dans le message de news:
Bonjour,
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code dans un processus depuis un autre processus sans passer par un mécanisme d'IPC ou de RPC quelconque (socket, COM, DCOM ou .Net remoting par exemple) . En tous cas, pas depuis que l'on a abandonné le monde du 16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire avec l'API GetInstanceData. Mais cela était basé sur le fait que tous les processus tournaient dans le même espace adresse. Cette incongruité n'a bien heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process id depuis la deuxième instance mais il est question ici de faire une sortie "propre" comme cela a été précisé plus haut :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Je pensais plutôt effectivement à quelque chose comme .NET remoting ce qui
pourrait être plus général et permettre d'ajouter facilement toute autre
fonction exposée (un peu comme le ngen.exe qui permet maintenant d'interagir
avec le service Windows correspondant...).
--
Patrice
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news: O4MeVzkpGHA.4116@TK2MSFTNGP03.phx.gbl...
Bonjour,
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code
dans un processus depuis un autre processus sans passer par un mécanisme
d'IPC ou de RPC quelconque (socket, COM, DCOM ou .Net remoting par
exemple) . En tous cas, pas depuis que l'on a abandonné le monde du
16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire
avec l'API GetInstanceData. Mais cela était basé sur le fait que tous les
processus tournaient dans le même espace adresse. Cette incongruité n'a
bien heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process
id depuis la deuxième instance mais il est question ici de faire une
sortie "propre" comme cela a été précisé plus haut :-) .
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je pensais plutôt effectivement à quelque chose comme .NET remoting ce qui pourrait être plus général et permettre d'ajouter facilement toute autre fonction exposée (un peu comme le ngen.exe qui permet maintenant d'interagir avec le service Windows correspondant...).
-- Patrice
"Patrick Philippot" a écrit dans le message de news:
Bonjour,
Ou peut-être détecter l'instance précédente au lancement
Ça, c'est facile.
et appeler la méthode permettant d'y mettre fin ?
Quelle méthode pourrait-on invoquer? On ne peut pas déclencher du code dans un processus depuis un autre processus sans passer par un mécanisme d'IPC ou de RPC quelconque (socket, COM, DCOM ou .Net remoting par exemple) . En tous cas, pas depuis que l'on a abandonné le monde du 16-bit.
Sous Windows 3.1, la manip en question était extrêmement simple à faire avec l'API GetInstanceData. Mais cela était basé sur le fait que tous les processus tournaient dans le même espace adresse. Cette incongruité n'a bien heureusement plus cours.
Vous pensiez peut-être à tuer le processus après avoir repéré son process id depuis la deuxième instance mais il est question ici de faire une sortie "propre" comme cela a été précisé plus haut :-) .
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
