Bonjour une petite question me traquasse et je ne trouve pas réponse.
Quelle conséquence cela a t'il de ne pas appeller la méthode dispose() d'une resource avant la fin du programme ?
Merci d'avance.
Bonjour une petite question me traquasse et je ne trouve pas réponse.
Quelle conséquence cela a t'il de ne pas appeller la méthode dispose() d'une resource avant la fin du programme ?
Merci d'avance.
SWT ne construit pas les composants(widgets) lui-même, il demande au système sur lequel il tourne de la faire, ce qui au niveau du système mobilise des ressources. Lorsque tu crée explicitement un widget
ex:tu dois libérer la ressource avant la fin du programme, sinon, tu ne dois pas le faire.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Label label=new Label(shell, SWT.CENTER);
Je ne comprend pas trés bien ce que tu veux dire.tu dois libérer la ressource avant la fin du programme, sinon, tu ne dois pas le faire.
Ma question s'orientait plutôt au niveau des "Resource" telles que Image, Color et Font, je voulais savoir si ça pose problème de ne pas les détruire quand je programme termine.
... Une seule chose à savoir : si tu utilise une ressource explicitement, tu dois la libérer après utilisation, que ce soit une image, ou font ...
Oui merci mais en fait j'aurais voulu savoir pourquoi est-ce qu'on doit le faire et si c'est nécessaire de le faire à chaque fois ou si le système d'exploitation se charge de détruire les ressources créées lorsque le programme termine, dans ce cas là ça ne servirais peut-être qu'à ne pas avoir trop de resources inutilisées en mémoire lorsque le programme tourne.
C'est juste de la curiosité pour comprendre pourquoi est-ce qu'on doit effectuer cette opération.
Prenons l'exemple d'une ressource de type "Font".
Tu créés un nouvel objet "Font" que tu associe à un widget (disons un label).
SWT va faire appel au système qui va allouer de la mémoire pour ton label ET pour ta police de caractères.
Lorsque tu quittes ton application, SWT va faire un "dispose" sur ta fenêtre et tout tes composants, par conséquence l'espace mémoire pour ton objet "Label" est libérer... Par contre, celui de ton objet "Font" ne l'est pas, et ne pourra pas être utilisé par aucune application.
Imagine une image de 32Ko créée 100 fois par ton problème, hop 3.2Mo de perdu ! Imagine sur des applications qui doivent tourner en permanence, on arrive vite à saturer le système.
J'espère que mon explication est claire![]()
Oui merci beaucoup c'est exactement ce que je voulais savoir.
Je rebondis sur ce poste pour savoir quel son les objets graphiques qu'il faut libérer par un dispose ?
Merci de vos réponse.
Tu dois libérer explicitement tout ceux qui étendent la classe Resource (Font, Image, Color, GC... ) et ceux qui étendent Device, sinon tu peux aussi appeller la méthode dispose() des widgets pour les détruire mais un widget est automatiquement détruit si tu détruit sont parent donc détruire une fenêtre détruira tout les composants qui lui sont directement ou indirectement liés.
Bonjour!
J'ai un souci avec une animation de chargement : je fais tourner un gif animé pendant la connexion à une BD, puisque lorsque la connexion est effectuée, le shell de l'animation pour patienter disparait et mon application se lance.
Tout se passe correctement, mais si je laisse mon programme lancé (il ne fait plus rien, il affiche juste les résultats de la BD) plusieurs minutes (20-30), j'ai une erreur (No more handles).
Il se trouve que je n'arrive pas à "disposer" l'image pour patienter pendant l'animation.
J'ai pourtant une méthode disposeMe que j'appelle :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9 public void disposeMe(){ sShell.dispose(); display.dispose(); image.dispose(); System.out.println("image disposed? "+image.isDisposed()); System.out.println("Waiting disposed? "+display.isDisposed()); System.out.println("shell waiting disposed? "+sShell.isDisposed()); }Qu'on m'explique pourquoi on m'indique que image n'est pas disposée alors que j'appelle bien image.dispose() ?Envoyé par console
PS : mon code pour cette fenêtre d'animation n'est rien d'autre que le snippet141 adapté...
Déjà ne crées pas un nouveau Display, utilises-en un seul pour ton application, je ne sais pas si ça résoudra le problème mais en SWT on pratique comme ça, en suite... je ne comprends pas trop, dans l'exemple que tu sites tu as vérifié que le résultat est différent de ce que tu obtiens ?
OK pour le display, j'essaierai au boulot.
Pour le problème, ça semble venir du snippet141, sûrement parce que le gif que je charge est un gif-animé infini. J'ai résolu en terminant le Thread qui raffraichit le gif animé à l'arrache, avec un .stop(). C'est pas beau mais je n'ai pas réussi à reproduire le problème (qui survient après 10-20 minutes d'inactivité du programme) en stoppant le thread
Normalement en SWT (je recommence lol) on utilises pas les Thread puisque le display et le widgets ne permet d'être accédé que par un seul Thread, mais des Runnable lancés en utilisant les méthodes syncExec(Runnable), asyncExec(Runnable) et timerExec(Runnable) du Display.
oui je sais pour les thread, mais je me base sur les snippet141 d'eclipse
http://dev.eclipse.org/viewcvs/index...va?view=markup
pour afficher un gif animé pendant une connexion à une BD. Si tu vois une autre solution qu'un thread en attendant la connexion ou un quelconque chargement, je suis prenneur.
Et le thread du snippet, c'est pour afficher le gif, c'est eclipe meme qui propose le snippet. C'est celui-là qui me posait problème apparemment.
Essaye de le transformer, plutôt que d'utiliser un Thread tu utilises un Runnable et tu remplace la boucle par un appel à display.timerExec('temps d'attente', this) en remplacent 'temps d'attente' par une valeur en millisecondes.
Je suis désolé j'ai pas le vraiment le temps nécessaire en ce moment pour faire le test.
non mais je vais laisser mon projet ainsi. C'était le thread du snippet qui posait problème à cause d'un gif animé qui tourne en boucle.
J'ai corrigé le problème, et c'est pas très important, je dispose ce shell après la connexion à la BD...
Partager