Salut et bienvenue sur ce forum,
Réponse:
Private Sub Form_Load() Unload Me End Sub
Donc, si j'ai bien compris, tu ouvres le "Gestionnaire de tâches" Windows pour fermer tes fenêtres...
Tu te prends la tête.
Dans une Fonction ou une sub, tu peux utiliser "STOP" (pause) ou "END" pour quitter ton programme.
Si ta fenêtre ne se ferme pas, c'est qu'un "tread" (hook sur un fichier data) n'est pas fermé avec un "RESET", ou si tu as une boucle infinie dans ton code.
Ctrl+Break (touche PRINT) ou Fn+Ctrl+P ferme une fenêtre avec un code circulaire en deboguage.
Amuse toi bien.
Bonjour,
Merci pour ton accueille,
Donc, si j'ai bien compris, tu ouvres le "Gestionnaire de tâches" Windows pour fermer tes fenêtres..
Pas du tout, ça serait trop simple...
Certaine fenêtre de Windows XP Pack 3 (oui je sais c'est vieux mais sa fonction encore très bien) son impossible
à fermer, c'est pour cela que j'ai développé ce petit programme.
Merci pour votre réponse
A+
.
Salut,
Malheureusement, il te sera difficile de solutionner ton problème avec ce genre de programmes.
La clôture impossible d'un fenêtre est le résultat d'un bogue des programmes concernés.
La pratique veut que le programme soit débogué à la source, et non par un programme tiers.
L'ouverture d'une fenêtre est gérée par une hiérarchie donnée par la configuration des fenêtres et par leurs déclaration d'appel.
Donc, si le tread de l'application chargée n'est pas mère, ou que la fenêtre esclave est bloquée sur une exécution extérieure... il te sera impossible de détécter la fenêtre et de la fermer.
J'ai été confronté à ce type de problème il y a quelques mois, et bloquer une OCX classique type droplist est très facile!
Il sera possible de fermer l'application, mais la fenêtre en attente de la validation de l'OCX ne se fermera pas.
Il te faudra utiliser un programme qui efface les liens actifs ActiveX pour purger les fenêtres en attente de fermeture, j'ai eu ... mais j'ai plus.
Ceci est un cas particulier que j'ai expérimenté sur une action "droplist_change" qui bloquait sur une mise à jour du contrôle lors de l’exécution d'une routine.
Il faut donc que tu traces tes programmes, et que tu prennes soins à déboguer tes routines par masquage de codes sur les actions d'appel de tes contrôles. En les mettant en REM et en fermant l'application compilée... C'est la méthode que j'ai utilisée.
Certains bogues sont mesquins, et le cas évoqué m'a fait chercher longtemps.
Mais, en règle général, tout sub-classing et échange avec une OCX peut provoquer des interactions pouvant désorganiser celle-ci... d'où des plantages inexpliqués.
Tu nous propose de mettre le feu aux roues de ta voiture, au lieu de mettre une roue de secours.
Tes programmes n'ont pas un fonctionnement normal, il te faut donc les modifier.
Mais, la récurrence du problème laisse plus à penser à un problème systémique du compilateur et non à un bogue isolé.
Je pense plus à des DLLs, OCXs... non compatibles avec ton compilateur, qu'a un problème de programmation.
N'étant pas expérimenté en RapidQ, il m'est impossible de t'aider plus précisément dans ton problème.
Désolé...