PrintJob.print évènement terminé!

Version imprimable

Bonjour,

Ayant un grand nombre de JPanel à imprimer, je souhaite libérer des ressources après l'impression de chaque JPanel.

Voici en résumé à quoi ressemble le code:
Code:

1 2 3 4 5 6 7 // l'appelle de print invoquera la méthode d'impression de monJPanel try { pj.print(); } catch (PrinterException pe) {;} // l'impression est terminée donc je libère le panel: monJPanel.finalize(); monJPanel = null;
Mon problème est le suivant:

soit je ne libère pas monJPanel et tout s'imprime correctement jusqu'à ce que je tombe en out of memory.
soit je libère monJPanel mais j'imprime alors une page vierge car je le libère visiblement trop tôt.

Ma question est la suivante:

existe-t-il un évènement à trapper qui permet de savoir que l'impression est terminée?

Question subsidiare:

Pouvez-vous m'indiquer un tutoriel précis sur la façon dont java traite cette méthode print qui visiblement s'exécute dans un thread indépendant?

Pour info:

Je n'ai pas trouvé de listener approprié (peut-être ai-je mal cherché? surement du reste puisque je n'ai pas trouvé de solution!)
J'ai essayé de tester le retour de la méthode public int print(Graphics g, PageFormat pf, int pageIndex) en attendant le NO_SUCH_PAGE (mais ce n'est pas concluant)
La seule solution que j'entrevois serait de tester le hashcode() du monJPanel utilisé dans la méthode public int print(Graphics g, PageFormat pf, int pageIndex) et de le libérer quand la valeur du hashcode() change (et donc qu'on commence l'impression du monJPanel suivant). Mais ça reste de la bidouille empirique...

Merci de votre aide

22/12/2010, 08h16
tchize_

vous avez juste à mettre le panel éventuellement à null. Le GC fera son boulot en temps et en heure. Si le panel n'est pas nettoyé, c'est que vous gardez ailleurs une référence sur ce panel. on appelle JAMAIS les méthode finalize soit même, elle sont destinée au gc, pour etre appelées quand l'objet est libéré.
22/12/2010, 09h22
hwoarang

Salut,

Si je me rappelle bien les tests que j'avais fait à l'époque, la fonction void print(Graphics graphics, PageFormat pageFormat, int pageIndex) est appelée quand tu fais printJob.print()

Autrement dit, au retour de printJob.print(), la tache est deja terminée. Par contre, comme précisé precedemment (ainsi que par la javadoc), c'est le garbage collector qui appelle finalize. Il faut simplement mettre ton jpanel à null et t'assurer qu'il n'y a plus de reference sur lui (s'il est inclu dans un autre container, ne pas oublier le remove).

Au passage, je ne sais pas si tu connais mais il est possible de lancer la machine virtuelle avec l'argument -Xmx pour augmenter la memoire allouée à celle-ci et eviter les out of memory.

a+

Merci pour vos réponses

Pour être plus précis, je n'appelle pas la méthode finalize(), mais finalizeMe() qui se contente de mettre à null tous les attributs du JPanel:
Code:

1 2 3 4 5 6 7 public void finalizeMe() { // planbay et selection sont aussi des extends JPanel dont la méthode finalizeMe() met à null les attributs selection.finalizeMe(); planbay.finalizeMe(); selection = null; planbay = null; }
Je savais qu'on pouvait allouer plus de mémoire à la JVM, mais il me semble que ce n'est pas très propre (est-ce une méthode courante?) et je préfèrerais comprendre où est mon erreur.

Si vous avez d'autres pistes je suis preneur.
Je vais déjà m'assurer de nouveau qu'aucun autre composant ne fait référence à monJPanel.
Merci

22/12/2010, 11h36
tchize_

vous ne devriez justement pas avoir besoin de mettre à null les attributs du panel, il seront libérés en meme temps que le panel le sera. Ce que vous faite est une bidouille pour retarder le problème (vous allégez le poids de l'objet qui traine en mémoire, alors que le problème est justement d'éviter qu'il traine).

Bref, retirer les références au panel. Et au printerJob, qui garde une référence sur le panel que vous avez passée via setPrintable.
22/12/2010, 12h53
hwoarang

Citation:

Envoyé par toutatafr

Je savais qu'on pouvait allouer plus de mémoire à la JVM, mais il me semble que ce n'est pas très propre (est-ce une méthode courante?) et je préfèrerais comprendre où est mon erreur.

Ca n'a rien de "sale". Ca depend de l'utilisation. Si le nombre de jpanels est connu à l'avance, il n'y a rien de problematique a augmenter la taille memoire pour pouvoir les gerer.
Maintenant, si les jpanels sont potentiellement illimités et temporaires, c'est sur qu'il est mieux de les liberer après usage...

Mais sur le principe, c'est pas choquant d'augmenter la taille memoire quand on en a besoin...
23/12/2010, 00h32
bouye

Ce qui est choquant c'est que malgré les améliorations apportées a Java 1.5, il faille encore faire cela manuellement.
23/12/2010, 09h12
tchize_

c'est une machine virtuelle, pour moi c'est normal de pouvoir lui imposer des limites, surtout quand la jvm est utilisée pour des applis serveur :roll:

Maintenant, clair qu'en desktop, ca devrais automatiquement être "le moins possible tout en ayant la possibilité d'utiliser tout le système en cs de besoin"
23/12/2010, 12h18
toutatafr

Après des modifications un peu partout plus rien ne fonctionne! :oops:
Je dois donc tout remettre d'aplomb puis je reprendrai mes tests! :roll:

Pour l'instant je suis en congé :ccool:

Merci pour votre aide, je reprendrai contact avec vous dès mon retour si malgré vos conseils je ne m'en sors pas :mur:

Bonne Fêtes à tous (il manque un smiley père noël!)

Bonjour,

Bonne Année à tous.

Je reviens vers vous pour mon problème d'impression.
Le message va peut-être devoir changer de forum...

Si j'ai bien compris le problème est le suivant:
Pour pouvoir imprimer un JPanel il faut d'abord l'afficher?
Dans mes premiers tests j'affichais mes panels dans des JFrame pour vérifier le contenu du dit panel et tout fonctionnait correctement.
Dorénavant j'affiche le panel dans une JDialog (avec deux bouton suspendre et annuler).
Pour être très précis: j'ajoute mon JPanel dans un JPanel se trouvant dans une JScrollPane se trouvant dans le contentPane de ma JDialog
Mais malgré mes appels à repaint ou update sur les différents éléments du JDialog, le panel n'est repeint que quand il a envie!

Pensez-vous que le problème puisse venir de là?
Le synchronized ne semble pas suffisant pour assurer que le repaint est bien fini.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 La JDialog observe mon modèle ma et est prévenue de la nécessité de mettre à jour le panel. /** Mettre à jour le panel de la bay */ private void updatePanelBay() { synchronized(this) { // je mets en pause le thread d'impression ma.setPauseEdit(true); if( pnlBay != null ) { // je supprime l'ancien panel à imprimer pnlBay.removeAll(); // s'il y a un nouveau panel à imprimer je l'ajoute au panel // puis je repaint tout ce que je peux... if (ma.getPanelBay() != null) { pnlBay.add(ma.getPanelBay()); // je repeins le panel ma.getPanelBay().update(ma.getPanelBay().getGraphics()); // je repeins le panel contenant le panel pnlBay.update(pnlBay.getGraphics()); // je repeins la JScrollPane jspBay.update(jspBay.getGraphics()); // je repeins la JDialog this.update(this.getGraphics()); ma.getPanelBay().repaint(); pnlBay.repaint(); jspBay.repaint(); this.repaint(); } } // je redémarre le thread d'impression ma.setPauseEdit(false); } }
Merci de votre aide

06/01/2011, 16h35
toutatafr

Bonjour,

La solution était d'utiliser la méthode validate() de la view du JScrollPane

Merci de votre
10/01/2011, 10h22
toutatafr

Et pour en finir avec ce problème (définitivement?)
Mon out of memory venait du fait que j'oubliais de désinscrire mon panel d'un Observable. J'avais donc toujours une référence valide sur mes panels qui n'étaient alors pas purgés.
Ainsi je n'ai pas besoin d'allouer plus de mémoire ce qui me plait bien

Merci encore