Ce sujet est résolu.
| 1 | |||
| Auteur | Messages | ||
|---|---|---|---|
| valaquarus | #1 Posté le 5/4/2019 à 19:42:44 | ||
-- Unus Ex Altera -- | Bonsoir, je viens de m'apercevoir en regardant l'occupation de la mémoire sur ma machine que j'avais des processus gbr3 qui continuaient à être présent malgré le fait que ces programmes étaient arrêtés depuis un moment est ce que quelqu'un a remarqué ce type de chose. Cela le fait avec mes programmes ou avec d'autres issus de la forge ou d'ailleurs. Si on redémarre la machine sans effacer de force ces processus quand le système se lance ces programmes se lancent aussi. Pourtant certains programmes sont prévus pour qu'une seule instance ne se lance et la nouvelle instance ne voit pas l'ancienne encore en mémoire. Suis je le seul et dans ce cas je dois incriminer ma machine mais quels correctifs y apporter si d'autres ont vécus la même chose il faut peut être faire remonter cela comme un bug ou bien? Philippe Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| spheris | #2 Posté le 7/4/2019 à 09:05:25 | ||
 | Effecivement tu as raison. J'ai bien constaté ce problème avec un ordi qui tourne depuis plus d'un an. Il y avait plus de 2300 instances de gbr3 en cours d'utilisation. Probablement un bug. La fonction close n'a pas l'air de tuer l'instance de la form en cours.  | ||
| valaquarus | #3 Posté le 7/4/2019 à 11:20:35 | ||
| -- Unus Ex Altera -- | Merci Spheris de ta réponse car je lutte contre ce truc depuis un moment. Dans l'ide déjà, ce problème apparaît on ne sait pas très bien pourquoi de façon très aléatoire le programme en test ne s'arrête pas tu es obligé de le tuer. J'ai regardé le répertoire temporaire de gambas et toutes les sessions mal arrêtées y figurent avec leur numéro de processus. Quand je fais le nettoyage par le vide du dit répertoire cela repart conformément à ce que cela devrait être jusqu'à la fois suivante qui intervient quand elle veut sans que j'ai pu repérer quelque chose de particulier qui aurait provoqué le blocage de l'arrêt dans l'ide. J'ai repéré deux choses qui ralentissent la fermeture : -l'utilisation d'un son sur la clôture provoque soit un retard soit une fermeture mais avec le processus qui continue en mémoire. -l’utilisation de Try dans un form_close provoque un ralentissement notable de la fermeture. Depuis que j'ai retiré ces deux choses de mes programmes, ils ferment plus rapidement (instantané) et le processus ne reste pas en mémoire. On aurait pu penser que j'y étais pour quelque chose directement mais un tas de programmes de la forge ou d'ailleurs provoque les mêmes choses sans qu'il n'y ait forcement les deux éléments dont je viens de te faire part, donc il y a d'autres raisons qui provoquent des difficultés de fermeture. Ma conclusion est que c'est une chose tabou car je n'ai pas retrouvé mention de ce problème dans aucun forum (je les ai tous fait) et depuis qu'existe Gambas cela aurait du être rapporté par quelqu'un et même corrigé si c'était un bug. Philippe. EDIT : j'ai lu que certains préfèrent utiliser QUIT qui laisse un tas de chose en mémoire mais qui tue radicalement le processus si bien qu'on ne le retrouve pas en mémoire et que le reste finit par être éliminé de la mémoire. J'ai essayé c'est effectif. Bizarrerie? Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| Foromus | #4 Posté le 10/4/2019 à 17:49:33 | ||
| Bonjour, Au passage, je remarque que j'avais déjà soulevé un problème similaire avec un affichage de photo, et qui saturait très vite la mémoire. Problème jamais résolu du reste, heureusement, ce projet n'avait rien d'indispensable... Il est probable que Gambas fonctionnera à peu près correctement dans quelques années... | |||
| valaquarus | #5 Posté le 10/4/2019 à 18:54:55 | ||
| -- Unus Ex Altera -- | Bonsoir Foromus, voilà que je me sens bien moins seul d'un coup. Oui c'est un truc bien étrange au niveau "comportement" car ce n'est pas régulier, on ne peut pas prédire la chose on ne peut que constater sans pouvoir interpréter (pour ma part car je n'en ai pas les capacités) C'est dommage de ne pas être entendu par ceux qui savent et qui pourraient trouver là de quoi bien améliorer la vision que certains ont de Gambas. Philippe Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| spheris | #6 Posté le 14/4/2019 à 08:14:26 | ||
| Une solution consisterait à mettre un 'QUIT' dans la fonction Me.Close() de la form principale et le tour est joué. | ||
| valaquarus | #7 Posté le 14/4/2019 à 10:45:07 | ||
| -- Unus Ex Altera -- | Déjà essayé et c'est vraiment caca. Le quit s'exprime avant tout le reste et il reste plein de truc en mémoire par contre le processus est éradiqué mais les fichiers temporaires ne sont pas effacés. J'ai placé un Wait à la fin de Me.Close(), sans conviction, mais en reprenant le wiki cela peut être la solution puisque la boucle d’événements est appelée tant que quelque chose remue la queue. Vraiment bizarre ce truc. Philippe Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| valaquarus | #8 Posté le 22/4/2019 à 11:01:56 | ||
| -- Unus Ex Altera -- | Je marque résolu mais cela ne l'est pas du tout mais j'en ai soupé alors au revoir Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| spheris | #9 Posté le 23/4/2019 à 20:46:14 | ||
| Une autre solution consiste à poser la question à Benoit, le concepteur sur la liste de diffusion. Mes capacités en programmation sont limitées et je ne peux malheureusement pas te répondre sur ces questions pointues. | ||
| linuxos | #10 Posté le 27/4/2019 à 00:05:47 | ||
Un peu de sel, de poivre et la crevette sera...  | Bonjour valaquerus, Concernant ton probleme, il faudrait nous indiquer la version de Gambas que tu utilises. En effet il a eu certaines versions qui posaient problème et qui ne se fermait pas correctement ou pas du tout. Il peut arriver que certains objets créer dans tes programmes ne soient pas correctement supprimés et donc Gambas ne peux pas quitter (cela reste rare tout de même). La aussi il faudra pouvoir consulter ton code pour t'aider. Nous faisons notre possible pour répondre selon nos compétences et nos dispositions bien sur. Olivier Lorsqu'on s'occupe d'informatique, il faut faire comme les canards... Paraître calme en surface et pédaler comme un forcené par en dessous. | ||
| valaquarus | #11 Posté le 28/4/2019 à 11:09:50 | ||
| -- Unus Ex Altera -- | Bonjour Linuxos, je suis toujours à la dernière version en cours, depuis le début de ce fil il s'agit de la version 3.12 que je viens de mettre à jour en 3.13. Pour les objets en mémoire, je les passe un par un au crible pour les fermer avant la fermeture du prog mais cela intervient de manière aléatoire sur n'importe lequel de mes prog ou des progr de la forge ou d'ailleurs. Pour les passionnés qui passent par ce forum il n'y a pas de ma part de récriminations car les passionnés finissent toujours par répondre aux questions qu'on leur posent même si c'est pour botter en touche, quand on ne sait pas on ne sait pas. Et je n'en veux à personne sauf peut être à ceux qui savent et qui ne répondent, eux, jamais ou qui font semblant de ne pas comprendre de quoi vous parlez. Philippe P.S. pour ce qui est du code, j'ai essayé de le poster sur la forge par l'ide comme directement mais je crois que cela n'a pas fonctionné mais là aussi c'est de ma faute sans autre explication. Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| valaquarus | #12 Posté le 30/4/2019 à 11:25:55 | ||
| -- Unus Ex Altera -- | Une solution consisterait à mettre un 'QUIT' dans la fonction Me.Close() de la form principale et le tour est joué. Bonjour Spheris, je te cite parce que je viens de faire ce que tu dis mais d'une certaine façon qui fonctionne très bien sans que j'en comprenne les raisons (quoi que!).
L'utilisation d'une form de façon modal laisse le temps de fermer tout ce qui est ouvert et libérer la mémoire à tel point que si on n'utilise pas le Quit, la form modal étant fermée tout reste figé et la mémoire n'est pas libérée par le programme. Tant que ça marche c'est finalement une bonne idée. Mais c'est très étrange et ne correspond pas à ce que l'on lit par ci par là. La Sub est ici dans un module principal. Philippe. P.S. : Au fait je viens de découvrir ce qu'est une fenêtre d'utilité, c'est une fenêtre normale mais avec un bug d'affichage sur la commande : Hide du contour de celle-ci qui ne s'affiche pas quand on appelle une deuxième fenêtre et que l'on revient vers la première. C'était pourquoi j'avais affiché ces deux icônes à droite de la fenêtre principale. J'ai mis cette propriété à false et plus besoin de ces icônes. Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| Flachy Joe | #13 Posté le 30/4/2019 à 19:44:01 | ||
Iguane : Il Gambas Uniquement pour Activer ses NEurones | à tel point que si on n'utilise pas le Quit, la form modal étant fermée tout reste figé Rassure moi : tu n'utilise pas Form.Hide pour fermer les fenêtres ? Parce que dans ce cas c'est tout à fait normal que le programme continue de tourner. Showmodal ne rend la main qu'avec un Form.Close et c'est la seule méthode qui détruit les contrôles de la fenêtre. P.S. : Au fait je viens de découvrir ce qu'est une fenêtre d'utilité, c'est une fenêtre normale mais avec un bug d'affichage sur la commande : Hide du contour de celle-ci qui ne s'affiche pas quand on appelle une deuxième fenêtre et que l'on revient vers la première. C'était pourquoi j'avais affiché ces deux icônes à droite de la fenêtre principale. J'ai mis cette propriété à false et plus besoin de ces icônes. J'ai rien pigé, c'est normal ? Flachy Joe | ||
| valaquarus | #14 Posté le 30/4/2019 à 22:44:03 | ||
| -- Unus Ex Altera -- | Bonsoir Flachy joe, non, je te rassures je n'en suis pas encore là mais mon âge avançant il se pourra que j'y arrive très vite. pour l'instant je reste encore alerte même si un peu cassé. C'est tout l'intérêt de showModal que de ne rendre la main qu'après un close, on na pas besoin d'un wait cent sept ans pour reprendre la main. Pour la fenêtre d'utilité c'est une propriété des form qui apparait d'ailleurs dans la liste des propriétés des form de l'ide, sans commentaire ni info autre que de suivre les standards du freedesktop mais quand on utilise celle-ci en la mettant à true il y a une gène d'affichage (sur QT) qui fait disparaître le bouton pour abaisser les fenêtres dès qu'on appelle une autre fenêtre et qu'on retourne sur la première, c'est un petit fil que Spheris et moi avons eu il y a un petit moment et c'était pour allez plus loin dans ce fil. Rien de bien étrange, en somme. Philippe Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 | ||
| 1 | |||