J'ai un programme qui tourne impec.
J'ai cependant une petite question :
Comment faire un programme sans interface ?
Sous VB je crérais un .mod par exemple.
Dans ce programme il y a un timer qui effectue la meme tache toutes les 5
minutes.
Actuellement il y a une fenetre (qui me permettait d'afficher dans une liste
l'ensemble des opérations effectuées, un peu comme une log), mais si je
supprime cette fenetre ou mettre le timer ?
A priori, WD n'aime pas les timer dans le code d'init des projets.
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
jacques trepp
Gilles Guédikian a écrit :
tjfromparis a formulé la demande :
Bonjour,
Actuellement il y a une fenetre (qui me permettait d'afficher dans une liste l'ensemble des opérations effectuées, un peu comme une log), mais si je supprime cette fenetre ou mettre le timer ?
A priori, WD n'aime pas les timer dans le code d'init des projets.
Je vois 2 solutions à ton problème
Une solution cochonne :
pourquoi cochonne ?? un simple projet, surtout pas de fenètre, utilisation de XYNTSERV pour gérer l'exe généré en tant que service. c'est simple, léger, et surtout, ça marche.
Init de projet : TimerSys("test",100) BOUCLE Multitâche(100) FIN
Ca fonctionne et ça ne consomme pas de CPU
Un solution plus chic : Faire un service avec WDService, et là nul besoin de fenêtre.
Gilles.
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Gilles Guédikian a écrit :
tjfromparis a formulé la demande :
Bonjour,
Actuellement il y a une fenetre (qui me permettait d'afficher dans une
liste l'ensemble des opérations effectuées, un peu comme une log),
mais si je supprime cette fenetre ou mettre le timer ?
A priori, WD n'aime pas les timer dans le code d'init des projets.
Je vois 2 solutions à ton problème
Une solution cochonne :
pourquoi cochonne ??
un simple projet, surtout pas de fenètre, utilisation de XYNTSERV pour
gérer l'exe généré en tant que service.
c'est simple, léger, et surtout, ça marche.
Init de projet :
TimerSys("test",100)
BOUCLE
Multitâche(100)
FIN
Ca fonctionne et ça ne consomme pas de CPU
Un solution plus chic :
Faire un service avec WDService, et là nul besoin de fenêtre.
Gilles.
--
Jacques Trepp
Albygest - 81160 - St Juery
jacques-pas de spam.trepp@free.fr
(enlever '-pas de spam' pour me joindre)
http://www.albygest.com
Actuellement il y a une fenetre (qui me permettait d'afficher dans une liste l'ensemble des opérations effectuées, un peu comme une log), mais si je supprime cette fenetre ou mettre le timer ?
A priori, WD n'aime pas les timer dans le code d'init des projets.
Je vois 2 solutions à ton problème
Une solution cochonne :
pourquoi cochonne ?? un simple projet, surtout pas de fenètre, utilisation de XYNTSERV pour gérer l'exe généré en tant que service. c'est simple, léger, et surtout, ça marche.
Init de projet : TimerSys("test",100) BOUCLE Multitâche(100) FIN
Ca fonctionne et ça ne consomme pas de CPU
Un solution plus chic : Faire un service avec WDService, et là nul besoin de fenêtre.
Gilles.
-- Jacques Trepp Albygest - 81160 - St Juery jacques-pas de (enlever '-pas de spam' pour me joindre) http://www.albygest.com
Romain PETIT
Gilles Guédikian avait soumis l'idée :
Un boucle sans point de sortie, c'est cochon, je ne changerais pas d'avis ;-)
Pourquoi sans point de sortie ? Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un multitache. Les timers c'est bien mais je crois avoir eu des soucis d'empliement et de débogage (surtout en utilisant des classes me semble-t-il). Quand aux threads, l'expérience de l'hyperthreading m'a refroidi...
Oui mais perso je préfère WDService parce que PCSoft en assure le support, et parce que ça fonctionne. Et tant que ça fonctionne en intégré, je ne vais pas voir ailleurs.
Ben moi je préfère la solution XYNTService parce que le support est également assuré (par l'auteur via un forum) mais également parce que j'ai une copie du code-source, et surtout parce qu'il est très facile à utiliser. Quand à l'intégration, elle est automatique désormais dans mes programmes grâce à une classe qui gère tout en auto et paramétrable à volonté : - le 1er lancement se fait avec l'option -installeService (cf WDSetup pour mettre une ligne de commande à la fin de l'installation) - extraction de XYNTService (grâce à l'utilitaire FichierDansExe de Michel Fages, XYNTService est en fait "dans" le code de ma classe) - paramétrage du Service (nom, fréquence de surveillance, exe à monitorer - lancement du service (code dérivé de la classe de Denis Reimstein) (-> là j'ai encore un petit problème si mon exe WD est monoinstance car c'est mon exe WD qui fait tout ça donc je ne peux pas lancer dans la foulée le lancement du service qui va lui même lancer l'exe...)
C'est un avis comme un autre, mais c'est le mien ;)
Il se défend mais quand ya mieux...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles Guédikian avait soumis l'idée :
Un boucle sans point de sortie, c'est cochon, je ne changerais pas d'avis ;-)
Pourquoi sans point de sortie ?
Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un
multitache.
Les timers c'est bien mais je crois avoir eu des soucis d'empliement et
de débogage (surtout en utilisant des classes me semble-t-il).
Quand aux threads, l'expérience de l'hyperthreading m'a refroidi...
Oui mais perso je préfère WDService parce que PCSoft en assure le support, et
parce que ça fonctionne. Et tant que ça fonctionne en intégré, je ne vais pas
voir ailleurs.
Ben moi je préfère la solution XYNTService parce que le support est
également assuré (par l'auteur via un forum) mais également parce que
j'ai une copie du code-source, et surtout parce qu'il est très facile à
utiliser.
Quand à l'intégration, elle est automatique désormais dans mes
programmes grâce à une classe qui gère tout en auto et paramétrable à
volonté :
- le 1er lancement se fait avec l'option -installeService (cf WDSetup
pour mettre une ligne de commande à la fin de l'installation)
- extraction de XYNTService (grâce à l'utilitaire FichierDansExe de
Michel Fages, XYNTService est en fait "dans" le code de ma classe)
- paramétrage du Service (nom, fréquence de surveillance, exe à
monitorer
- lancement du service (code dérivé de la classe de Denis Reimstein)
(-> là j'ai encore un petit problème si mon exe WD est monoinstance car
c'est mon exe WD qui fait tout ça donc je ne peux pas lancer dans la
foulée le lancement du service qui va lui même lancer l'exe...)
C'est un avis comme un autre, mais c'est le mien ;)
Il se défend mais quand ya mieux...
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Un boucle sans point de sortie, c'est cochon, je ne changerais pas d'avis ;-)
Pourquoi sans point de sortie ? Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un multitache. Les timers c'est bien mais je crois avoir eu des soucis d'empliement et de débogage (surtout en utilisant des classes me semble-t-il). Quand aux threads, l'expérience de l'hyperthreading m'a refroidi...
Oui mais perso je préfère WDService parce que PCSoft en assure le support, et parce que ça fonctionne. Et tant que ça fonctionne en intégré, je ne vais pas voir ailleurs.
Ben moi je préfère la solution XYNTService parce que le support est également assuré (par l'auteur via un forum) mais également parce que j'ai une copie du code-source, et surtout parce qu'il est très facile à utiliser. Quand à l'intégration, elle est automatique désormais dans mes programmes grâce à une classe qui gère tout en auto et paramétrable à volonté : - le 1er lancement se fait avec l'option -installeService (cf WDSetup pour mettre une ligne de commande à la fin de l'installation) - extraction de XYNTService (grâce à l'utilitaire FichierDansExe de Michel Fages, XYNTService est en fait "dans" le code de ma classe) - paramétrage du Service (nom, fréquence de surveillance, exe à monitorer - lancement du service (code dérivé de la classe de Denis Reimstein) (-> là j'ai encore un petit problème si mon exe WD est monoinstance car c'est mon exe WD qui fait tout ça donc je ne peux pas lancer dans la foulée le lancement du service qui va lui même lancer l'exe...)
C'est un avis comme un autre, mais c'est le mien ;)
Il se défend mais quand ya mieux...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
Gilles Guédikian avait prétendu :
Pourquoi sans point de sortie ? Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un multitache.
Oui mais pour informer le programme, il faudra faire appel à une bidouille comme un fichier ini ou une clé de registre, je trouve ça moyen. Je préfère arrêter un service ;)
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT. Parallèlement, on peut optionnellement mettre à vrai le booléen (via socket, message windows, fichier ini ou autre) pour sortir de la boucle et arreter le programme de lui même (mais il sera relancé par XYNT en fonction du paramétrage de ce dernier).
A ce propos, j'ai lu ceci dans la description de WDService : "NB : Pour créer son propre service en WinDev, se reporter au projet WDSerNT." Mais je n'ai jamais trouvé ce projet. Existe-t-il vraiment ? WDSerNT n'est pas écrit en Windev il me semble. J'ai pour ma part tenté un fois de créer directement un service avec WD mais je n'y suis pas parvenu (encore un problème de call back sur une des API, StartServiceCtrlDispatcherA je crois)
- le 1er lancement se fait avec l'option -installeService (cf WDSetup pour mettre une ligne de commande à la fin de l'installation)
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-)) Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour Inno Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec WDSetup (mais j'ai très peu de déploiements, et mes applis sont déployées à très petite échelle). Et puis j'utilise parfois les mises à jour automatiques (sur un LAN) intégrées, ça marche plutôt bien (même si le principe de lire un INI distant me gène un peu). C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les sources sont également disponibles (en Delphi je crois ?)
- extraction de XYNTService (grâce à l'utilitaire FichierDansExe de Michel Fages, XYNTService est en fait "dans" le code de ma classe)
Pourquoi l'intégrer? Une fois qu'il sera extrait, ca change quoi par rapport à l'installation du fichier dès l'origine par l'install?
Je n'ai pas besoin de préciser à WDSetup (ou n'importe quel autre outil d'install) le(s) fichier(s) supplémentaire(s) à déployer. Mon exe est autonome, totalement. Je suis certain que les fichiers extraits sont à la bonne version. Bref, je n'ai plus à y penser. Je vais d'ailleurs utiliser cette méthode pour mes acces natifs AS 400 (j'ai parfois des conflits de versions si je ne fais pas attention aux version des fichiers Easycom déployés).
Ohhh le mieux, c'est très subjectif ;-)
Evidemment, dans le cas contraire il n'y aurait pas lieu à discussion ;-)
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Gilles Guédikian avait prétendu :
Pourquoi sans point de sortie ?
Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un
multitache.
Oui mais pour informer le programme, il faudra faire appel à une bidouille
comme un fichier ini ou une clé de registre, je trouve ça moyen. Je préfère
arrêter un service ;)
Pas du tout.
L'arret du programme WD est effectué par XYNT, de la même manière que
WDSerNT.
Parallèlement, on peut optionnellement mettre à vrai le booléen (via
socket, message windows, fichier ini ou autre) pour sortir de la boucle
et arreter le programme de lui même (mais il sera relancé par XYNT en
fonction du paramétrage de ce dernier).
A ce propos, j'ai lu ceci dans la description de WDService :
"NB : Pour créer son propre service en WinDev, se reporter au projet
WDSerNT."
Mais je n'ai jamais trouvé ce projet. Existe-t-il vraiment ?
WDSerNT n'est pas écrit en Windev il me semble.
J'ai pour ma part tenté un fois de créer directement un service avec WD
mais je n'y suis pas parvenu (encore un problème de call back sur une
des API, StartServiceCtrlDispatcherA je crois)
- le 1er lancement se fait avec l'option -installeService (cf WDSetup pour
mettre une ligne de commande à la fin de l'installation)
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-))
Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour Inno
Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec
WDSetup (mais j'ai très peu de déploiements, et mes applis sont
déployées à très petite échelle).
Et puis j'utilise parfois les mises à jour automatiques (sur un LAN)
intégrées, ça marche plutôt bien (même si le principe de lire un INI
distant me gène un peu).
C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande
échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les
sources sont également disponibles (en Delphi je crois ?)
- extraction de XYNTService (grâce à l'utilitaire FichierDansExe de Michel
Fages, XYNTService est en fait "dans" le code de ma classe)
Pourquoi l'intégrer? Une fois qu'il sera extrait, ca change quoi par rapport
à l'installation du fichier dès l'origine par l'install?
Je n'ai pas besoin de préciser à WDSetup (ou n'importe quel autre outil
d'install) le(s) fichier(s) supplémentaire(s) à déployer.
Mon exe est autonome, totalement.
Je suis certain que les fichiers extraits sont à la bonne version.
Bref, je n'ai plus à y penser.
Je vais d'ailleurs utiliser cette méthode pour mes acces natifs AS
400 (j'ai parfois des conflits de versions si je ne fais pas attention
aux version des fichiers Easycom déployés).
Ohhh le mieux, c'est très subjectif ;-)
Evidemment, dans le cas contraire il n'y aurait pas lieu à discussion
;-)
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Pourquoi sans point de sortie ? Il suffit de prévoir une sortie à l'aide d'un booléen et de mettre un multitache.
Oui mais pour informer le programme, il faudra faire appel à une bidouille comme un fichier ini ou une clé de registre, je trouve ça moyen. Je préfère arrêter un service ;)
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT. Parallèlement, on peut optionnellement mettre à vrai le booléen (via socket, message windows, fichier ini ou autre) pour sortir de la boucle et arreter le programme de lui même (mais il sera relancé par XYNT en fonction du paramétrage de ce dernier).
A ce propos, j'ai lu ceci dans la description de WDService : "NB : Pour créer son propre service en WinDev, se reporter au projet WDSerNT." Mais je n'ai jamais trouvé ce projet. Existe-t-il vraiment ? WDSerNT n'est pas écrit en Windev il me semble. J'ai pour ma part tenté un fois de créer directement un service avec WD mais je n'y suis pas parvenu (encore un problème de call back sur une des API, StartServiceCtrlDispatcherA je crois)
- le 1er lancement se fait avec l'option -installeService (cf WDSetup pour mettre une ligne de commande à la fin de l'installation)
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-)) Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour Inno Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec WDSetup (mais j'ai très peu de déploiements, et mes applis sont déployées à très petite échelle). Et puis j'utilise parfois les mises à jour automatiques (sur un LAN) intégrées, ça marche plutôt bien (même si le principe de lire un INI distant me gène un peu). C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les sources sont également disponibles (en Delphi je crois ?)
- extraction de XYNTService (grâce à l'utilitaire FichierDansExe de Michel Fages, XYNTService est en fait "dans" le code de ma classe)
Pourquoi l'intégrer? Une fois qu'il sera extrait, ca change quoi par rapport à l'installation du fichier dès l'origine par l'install?
Je n'ai pas besoin de préciser à WDSetup (ou n'importe quel autre outil d'install) le(s) fichier(s) supplémentaire(s) à déployer. Mon exe est autonome, totalement. Je suis certain que les fichiers extraits sont à la bonne version. Bref, je n'ai plus à y penser. Je vais d'ailleurs utiliser cette méthode pour mes acces natifs AS 400 (j'ai parfois des conflits de versions si je ne fais pas attention aux version des fichiers Easycom déployés).
Ohhh le mieux, c'est très subjectif ;-)
Evidemment, dans le cas contraire il n'y aurait pas lieu à discussion ;-)
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
tjfromparis
est ce que l'une ou l'autre des méthodes fait apparaitre le service dans le gestionnaire de services Windows ?
et peut ton telediffuser l'ensemble (donc install auto em mode commande)
"Gilles Guédikian" a écrit dans le message de news:
Romain PETIT a exprimé avec précision :
Gilles Guédikian avait prétendu :
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT.
Okay, c'est pas mal. Donc en théorie, même si le programme est planté sévèrement, XYNT sait le killer?
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-)) Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour Inno Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec WDSetup (mais j'ai très peu de déploiements, et mes applis sont déployées à très petite échelle). Et puis j'utilise parfois les mises à jour automatiques (sur un LAN) intégrées, ça marche plutôt bien (même si le principe de lire un INI distant me gène un peu). C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les sources sont également disponibles (en Delphi je crois ?)
Oui c'est du Delphi et surtout c'est très propre et bien documenté. Et surtout, pour quelqu'un qui gère 7-8 langues dans l'appli, l'avantage est de disposer de version bien traduites de l'outil d'install. La désinstallation est très propre et efficace. Sans parler de la taille de l'installeur, rien à voir avec WDSetup, que PCSoft aurait pu écrire directement en C++ plutôt qu'en Windev.
est ce que l'une ou l'autre des méthodes fait apparaitre le service dans le
gestionnaire de services Windows ?
et peut ton telediffuser l'ensemble (donc install auto em mode commande)
"Gilles Guédikian" <boulot_SANSPOURRIEL_@neogie.com> a écrit dans le message
de news: mn.4c757d591d7ed409.21586@neogie.com...
Romain PETIT a exprimé avec précision :
Gilles Guédikian avait prétendu :
Pas du tout.
L'arret du programme WD est effectué par XYNT, de la même manière que
WDSerNT.
Okay, c'est pas mal.
Donc en théorie, même si le programme est planté sévèrement, XYNT sait le
killer?
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-))
Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour
Inno Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec
WDSetup (mais j'ai très peu de déploiements, et mes applis sont déployées
à très petite échelle).
Et puis j'utilise parfois les mises à jour automatiques (sur un LAN)
intégrées, ça marche plutôt bien (même si le principe de lire un INI
distant me gène un peu).
C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande
échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les
sources sont également disponibles (en Delphi je crois ?)
Oui c'est du Delphi et surtout c'est très propre et bien documenté.
Et surtout, pour quelqu'un qui gère 7-8 langues dans l'appli, l'avantage
est de disposer de version bien traduites de l'outil d'install.
La désinstallation est très propre et efficace.
Sans parler de la taille de l'installeur, rien à voir avec WDSetup, que
PCSoft aurait pu écrire directement en C++ plutôt qu'en Windev.
est ce que l'une ou l'autre des méthodes fait apparaitre le service dans le gestionnaire de services Windows ?
et peut ton telediffuser l'ensemble (donc install auto em mode commande)
"Gilles Guédikian" a écrit dans le message de news:
Romain PETIT a exprimé avec précision :
Gilles Guédikian avait prétendu :
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT.
Okay, c'est pas mal. Donc en théorie, même si le programme est planté sévèrement, XYNT sait le killer?
Tu ne veux pas utiliser WDService mais tu utilises WDSetup ?? ;-)) Moi en revanche, ca fait des lustres que j'ai abandonné cet outil pour Inno Setup...
Pour l'instant je n'ai pas rencontré de contrainte particulière avec WDSetup (mais j'ai très peu de déploiements, et mes applis sont déployées à très petite échelle). Et puis j'utilise parfois les mises à jour automatiques (sur un LAN) intégrées, ça marche plutôt bien (même si le principe de lire un INI distant me gène un peu). C'est vrai que si un jour je bloque ou que j'ai un déploiement à grande échelle, je n'hésiterai pas à utiliser Inno qui est gratuit et dont les sources sont également disponibles (en Delphi je crois ?)
Oui c'est du Delphi et surtout c'est très propre et bien documenté. Et surtout, pour quelqu'un qui gère 7-8 langues dans l'appli, l'avantage est de disposer de version bien traduites de l'outil d'install. La désinstallation est très propre et efficace. Sans parler de la taille de l'installeur, rien à voir avec WDSetup, que PCSoft aurait pu écrire directement en C++ plutôt qu'en Windev.
Romain PETIT
Il se trouve que Gilles Guédikian a formulé :
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT.
Okay, c'est pas mal. Donc en théorie, même si le programme est planté sévèrement, XYNT sait le killer?
Si le processus se termine, XYNT le rélancera (un paramètre dans le fichier INI de XYNT précise la fréquence de surveillance du (des) exe à monitorer. Par contre si le processus est gelé...
Pour un ensemble d'applications plus critiques, j'ai pallié à ça en rajoutant un niveau : - "A" fait son job de tâche de fond (et périodiquement met à jour un fichier/ini/donnée HF ou bien répond à un socket de B) - "B" n'a qu'une seule tâche : surveiller l'EXE A (vérifie la présence du processus et s'il est toujours actif (via fichier externe ou socket). Si A ne répond pas au bout d'un temps déterminé, B le kill puis le relance. - XYNT surveille/monitore "B"
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Il se trouve que Gilles Guédikian a formulé :
Pas du tout.
L'arret du programme WD est effectué par XYNT, de la même manière que
WDSerNT.
Okay, c'est pas mal.
Donc en théorie, même si le programme est planté sévèrement, XYNT sait le
killer?
Si le processus se termine, XYNT le rélancera (un paramètre dans le
fichier INI de XYNT précise la fréquence de surveillance du (des) exe à
monitorer.
Par contre si le processus est gelé...
Pour un ensemble d'applications plus critiques, j'ai pallié à ça en
rajoutant un niveau :
- "A" fait son job de tâche de fond (et périodiquement met à jour un
fichier/ini/donnée HF ou bien répond à un socket de B)
- "B" n'a qu'une seule tâche : surveiller l'EXE A (vérifie la présence
du processus et s'il est toujours actif (via fichier externe ou
socket).
Si A ne répond pas au bout d'un temps déterminé, B le kill puis le
relance.
- XYNT surveille/monitore "B"
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Pas du tout. L'arret du programme WD est effectué par XYNT, de la même manière que WDSerNT.
Okay, c'est pas mal. Donc en théorie, même si le programme est planté sévèrement, XYNT sait le killer?
Si le processus se termine, XYNT le rélancera (un paramètre dans le fichier INI de XYNT précise la fréquence de surveillance du (des) exe à monitorer. Par contre si le processus est gelé...
Pour un ensemble d'applications plus critiques, j'ai pallié à ça en rajoutant un niveau : - "A" fait son job de tâche de fond (et périodiquement met à jour un fichier/ini/donnée HF ou bien répond à un socket de B) - "B" n'a qu'une seule tâche : surveiller l'EXE A (vérifie la présence du processus et s'il est toujours actif (via fichier externe ou socket). Si A ne répond pas au bout d'un temps déterminé, B le kill puis le relance. - XYNT surveille/monitore "B"
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
tjfromparis a exposé le 09/09/2005 :
est ce que l'une ou l'autre des méthodes fait apparaitre le service dans le gestionnaire de services Windows ?
Pour WDServNT oui, je suppose.
Pour XYNT, oui. On peut même choisir le nom du service. (mais pas la description)
et peut ton telediffuser l'ensemble (donc install auto em mode commande)
hum...jamais essayé.
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
tjfromparis a exposé le 09/09/2005 :
est ce que l'une ou l'autre des méthodes fait apparaitre le service dans le
gestionnaire de services Windows ?
Pour WDServNT oui, je suppose.
Pour XYNT, oui. On peut même choisir le nom du service.
(mais pas la description)
et peut ton telediffuser l'ensemble (donc install auto em mode commande)
hum...jamais essayé.
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
