Ce sujet est résolu.
| 1 | |
| Auteur | Messages |
|---|---|
| Foromus | #1 Posté le 19/12/2022 à 12:27:46 |
| Bonjour, Dans mes projets, j'utilise, pour la conception, un volume chiffré. Pour l'utilisation, j'utilise aussi un volume chiffré. (A chacun ses petites manies....) J'ai créé, il y a plusieurs années, un gestionnaire pour déplacer et renommer des fichiers, et j'ai voulu l'améliorer. (La raison de mon post sur "DirChooser"). Lors des essais, ça fonctionne correctement, bien que le nombre de fichiers soit réduits pour ces essais. Il se trouve que je veux utiliser ce projet dans un autre volume chiffré, et, à première vue, ça marche aussi. Seulement voilà, quand je veux démonter ce volume chiffré d'utilisation, le démontage m'est refusé, au fallacieux prétexte qu'il serait toujours avec une opération encore en cours, ce qui interdit le démontage, ce qui est normal. Mais il n'y a plus d'opération en cours, tout est bien arrêté et fermé, et du reste, tous mes projets se terminent de la même manière : fermeture systématique de toutes les Form, et après "Quit". Malgré cela, il y aurait encore un truc qui tournerait en tâche de fond ? J'ai regardé dans le gestionnaire de tâches, justement, à vrai dire, il y a bien des petits trucs qui tournent, mais je peux supposer qu'ils appartiennent au système, pas à mon application, surtout que dans les noms affichés, aucun ne ressemble, de près ou de loin, à mon code. J'ai aussi remarqué, et depuis longtemps déjà, que dans certains cas de copie / renommage, il se trouvait que des répertoires cachés (.comments), apparaissaient assez bizarrement dans certains endroits. J'ai donc affublé mon appli d'une recherche et d'éradiction systématique des ces machins encombrants, d'autant que pour les virer, il faut faire semblant de virer avant les éventuels fichiers qu'ils pourraient contenir, bien que je n'aie jamais rien vu, ces répertoires s'affichent absolument et intégralement vides. Est-ce qu'il y aurait une parenté avec la corbeille, je n'ai rien trouvé non plus dans ladite. Bon, c'est un peu casse-pied, d'autant que la seule issue pour m'en sortir est de tenter un redémarrage de l'ordinateur, le quel met du reste un "certain temps" avant de s'exécuter. Je poste ici pour savoir si un problème de ce genre a déjà été entrevu, pour la solution, je ferai d'autres investigations par la suite, mais sans vouloir tirer des conclusions hâtives, j'ai quand même un peu l'impression que ça coince depuis que j'ai voulu tabasser mes "DirChooser", cela dit, je n'ai aucune certitude... | |
| valaquarus | #2 Posté le 21/12/2022 à 09:01:56 |
-- Unus Ex Altera -- | Bonjour Foromus, j'ai connu ce que tu décris dans un de mes programmes qui bien que fermé laissait plein de résidus et je ne comprenais pas d'où cela pouvait provenir, plutôt qu'un long discours je te renvoie à ce lien : https://gambas-fr.org/wiki/exemple9 Quand on touche aux fichiers en lançant une commande, celle-ci n'est réellement traitée que "plus tard" (boucle des évènements) d'où un problème lors de la fermeture du programme, pour éviter cela il faut juste après la commande rajouter le mot : Wait pour effectuer celle-ci immédiatement sans attente et sans compromettre la bonne fermeture du programme. Philippe Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 |
| Foromus | #3 Posté le 21/12/2022 à 11:48:44 |
| Bonjour valaquarus, Merci pour ce renseignement. J'avais un peu pensé à ça - je veux dire - problème de fichiers car, effectivement, j'ai bien rajouté deux fichiers pour garder les chemins en mémoire. (Ce qui n'est peut-être pas une bonne idée concernant l'utilisation de ce programme...) J'ai donc ressorti une version précédente et testé : ça marche correctement. Mon idée était de rajouter les modifications les unes après les autres, histoire de voir où ça coince. Je ne comprends pas trop la phrase : " il faut juste après la commande rajouter le mot : Wait pour effectuer celle-ci immédiatement". Normalement, la commande wait (complétée d'une valeur), est destinée à bloquer temporairement le logiciel d'une durée correspondant à la valeur renseignée, c'est pourquoi, wait et immédiatement me laissent songeur... J'avais d'ailleurs un peu anticipé, et la partie de mon code comprend plusieurs fois la commande wait. Bon, merci, je vais voir le lien. ..... (La moitié de mon message ci-dessus diparue....) Pour info : J'ai rajouté un wait 0.5 rien de changé, impossible de sortir ! Je continue mes investigations. | |
| valaquarus | #4 Posté le 21/12/2022 à 14:13:17 |
| -- Unus Ex Altera -- | Rebonjour Foromus, c'est bien wait sans délai pour obliger la boucle d'évènements à tourner de suite. Je sais, moi aussi je n'ai pas compris comment "attendre" faisait faire les choses sans attendre mais c'est bien effectif. Philippe Regardes ici : Wait Système d'exploitation : KDE neon 6.0 ~ Version Gambas : 3.19.5 |
| Foromus | #5 Posté le 21/12/2022 à 18:48:14 |
| RE, Effectivement, dans le code, lorsqu'on met le contrôle, une infobulle donne ce qu'il y a dans le lien. J'ai donc mis le wait seul, mais aucun changement, toujours le blocage de sortie. Ceci dit, j'ai contourné, et enlevé mes fichiers de chemins, je pense que c'est ça qui me met le bazar. Du coup, j'ai considéré une autre approche, mieux adaptée et qui simplifie mon code... Je m'étonne quand même que ça fonctionne bien dans un volume, et pas dans l'autre, le mode de chiffrage étant le même, mais il est vrai que ces deux volumes ont des tailles très très différentes. Du reste, j'avais déjà eu des soucis un peu similaires avec une application qui saturait la RAM en un clin d'œil, depuis, ayant sérieusement augmenté la taille de ladite, le problème ne se pose plus. J'ai quand même bien l'impression que Gambas ne maîtrise pas totalement la vidange des différentes mémoires à la sortie, peut-être y-a-t'il encore à voir de de côté, bien que l'ensemble soit maintenant vraiment performant. Mon nouveau code semble donner satisfaction, je verrai dans des utilisations concrètes, je n'en ai pas besoin pour l'instant. Je vais quand même passez en "Résolu" car le tour de la question a bien été fait ! Merci encore ! | |
| 1 | |