Discussion :

[fredclc]

Bonjour,

Voici mon problème... Il y a peu j'utilisais un logiciel sous Unix dans lequel je lançais des macros, or de temps en temps il arrivait qu'une macro ou une fonction bloque et ne me rende plus la main !
Il me suffisait de faire un 'kill -4' et le systeme me rendait la main sans fermer le logiciel donc le dit processus. Ceci me permetait de relancer manuellement la macro avec quelques modifs et hop le tour était joué.
Malheureusement nous avons du migrer ce même logiciel avec les mêmes macros sous windows XP et maintenant je ne peux que tuer le processus, equivalent du 'kill -9' sous unix.
Je ne peux plus reprendre la main sur la macro et je suis dans la m**** !
Existe-t-il un solution viable qui me donnerai l'aquivalent de ce 'kill -4' sous Unix ?

Merci de votre aide.
FRED

[Viduc]

quand tu fais Ctrl+Alt+Supp, tu arrives dans le gestionnaire des tâches... dedans tu ne vois pas ton processus????

[Mac LAK]

Et c'est quel signal, ce '-4' ? Est-ce qu'il est géré sous le portage Windows de ton programme ? As-tu utilisé les outils cygwin (par exemple) permettant d'envoyer ces signaux ?

Parce que si tu utilises "TaskKill", ce n'est pas prévu pour envoyer un signal, mais bel et bien pour flinguer abruptement et sans préavis un processus... C'est strictement impossible d'intercepter ce flinguage sous Windows, d'ailleurs, cela fonctionne nettement plus comme un delete dans la table des processus que comme une sorte d'exception/signal non géré.

[fredclc]

Bonjour,

Je peux effecitvement tuer mon processus avec le gestionnaire des tâches, mais c'est justement ce que je veux éviter, je veux juste arrêter la commande qui plante dans ma macro...
Dans la doc Unix dont je dispose le '-4' correspond au signal 'SIGALRM' alors que le '-9' correspond au signal 'SIGKILL'.
Je ne connais pas 'cygwin', à quoi sert-il exactement ? Je suis au taf et je n'ai pas accès à Google, mais je vais le chercher ce soir.

Merci.

[Mac LAK]

Je peux effecitvement tuer mon processus avec le gestionnaire des tâches, mais c'est justement ce que je veux éviter, je veux juste arrêter la commande qui plante dans ma macro...

Oui, mais là, t'es sous Windows et non pas Unix. Sous Windows, on ne se sert pas des signaux comme "messagerie", les messages existent déjà et/ou on utilise des systèmes différents pour contrôler les threads ou sous-processus.

Tu n'as d'ailleurs aucun outil natif sous Windows pour envoyer un tel signal ! Cygwin (un environnement Posix pour Windows) en possède sûrement un, mais encore faut-il que ton programme soit bien porté sous Windows via Cygwin, et que le code de gestion des signaux n'aie pas été désactivé... N'oublie pas : sous Windows, le "kill", c'est la vraie traduction, c'est réellement fait pour tuer le processus et non pas simplement lui envoyer un signal.

Classiquement, sous Windows, on ferait plutôt tourner la macro dans un thread dédié, avec un bouton sur l'IHM principale (et donc tournant dans le thread principal aussi) permettant d'arrêter la macro, en demandant d'arrêter le thread (proprement d'abord, puis violemment si ça ne marche pas)... Gérer un signal externe n'est tout simplement pas "naturel" pour la plupart des dévs Windows.

[fredclc]

C'est plutôt délicat !
C'est un logiciel professionnel de Cocreate, j'éspère qu'ils ont prévu ça...
En lisant la doc de Cygwin je suis tombé sur la commande kill et le signal 4 correspond à une instruction illégale qui n'a pas été initialisée... Ca irait bien avec mon problème...
De toute façon je vais essayer Cigwin ce soir et voir ce que ça donne, avec un peu de chance... Sinon je ne vois pas comment me sortir du problème... Satané Windows

[Mac LAK]

Sinon je ne vois pas comment me sortir du problème... Satané Windows

Du calme, le problème n'est pas Windows à ce niveau, mais des développeurs incompétents qui portent leurs logiciels comme des gorets : quand on migre un soft sur un OS, la moindre des choses, c'est de s'adapter aux principes, usages et règles de l'OS visé.
Ce qu'ils n'ont apparemment pas fait, tout comme ils n'ont pas résolu le bug de plantage des macros au passage d'ailleurs...

[fredclc]

Oui d'ailleurs on a fait une demande officelle à PTC et ils ne sont pas chaud pour résourdre de problème... C'est sur que c'était une solution de secour mais elle était bien pratique !!!

[maxim_um]

Salut,

tout comme ils n'ont pas résolu le bug de plantage des macros au passage d'ailleurs...

C'est évidemment le point le plus important.

C'est sur que c'était une solution de secour mais elle était bien pratique !!!

N'empêche que c'est pas une bonne pratique.

Ton logiciel doit bien avoir un bouton stop quelque part. Ou permettre l'usage d'une combinaison de touches pour arrêter un traitement. C'est quand même le b.a.-ba de tout programme qui accepte des séquences de commandes, des scripts ou encore des macros comme tu dis.

Enfin bref, y'a moult façons d'envoyer un message à un programme sous Windows. Maintenant est-ce que la gestion de ceux-ci a été implémentée à leur logiciel? C'est une autre histoire.

Sans les sources ou le programme en questions, il sera difficile de t'aider.

Oui d'ailleurs on a fait une demande officelle à PTC et ils ne sont pas chaud pour résourdre de problème...

Faut peut-être pas leur laisser le choix. Une modification dans ce sens prend dix minutes à tout cassées. un "virtual key accelerator" et hop.

[fredclc]

Merci pour vos reponses...

Mais que c'est compliqué en entreprise !
PTC est le fournisseur du logiciel, d'anciens collègues ont developpé un environnement logiciel et les macros et moi je me suis choppé la migration vers windows sachant que chez nous on ne peut pas embaucher un informaticien en bureau d'étude quand bien même celui-ci a besoin d'un developpeur... Oui je sais ça sent l'administration Donc pour ma part je suis dessinateur industriel et autodidact en informatique ( d'ou ma mission de migration, je pense ).
Et c'est sans compter sur les budgets...
M'enfin je vais continuer dans ce sens et essayer de les faire plier

FRED