Bonjour,

Je reçois des messages type JMS dont j'affiche un résumé sur un 
JTextPane. (enfin, quand je dis "je", vous aurez compris que c'est 
pas moi, evidemment).

A chaque fois que "je" mets le Document du JTextPane à jour, je 
voudrais que le JTextPane scroll vers le bas pour afficher 
automatiquement le dernier message reçu.

Pour se faire, j'envoie un scrollRectToVisible sur mon JTextPane et 
tout fonctione bien.

SAUF que si je le fais directos dans le thread qui a reçu le message tout
plante : en effet, je suis pas dans le "eventdispatchingthread" et j'ai
pas le droit.

Je fais alors un SwingUtilities.invokeLater d'un Runnable, et tout 
fonctionne à merveille.

Le souci, c'est que chaque fois que je reçois un message je crée un 
nouveau Runnable, et je trouve ça lourdingue. Je voudrais ne scroller vers
le bas que lorsque c'est vraiment utile, ou bien ne pas donner l'ordre de
rescroller vers le bas si je l'ai déjà demandé, ou bien ne pas créer un
nouveau thread à chaque fois...

Sachant qu'il m'est impossible de savoir à l'avance si j'ai encore 
des messages JMS à recevoir (ou alors j'ai mal lu la doc JMS), que 
pourrais-je faire pour optimiser ce processus ?

Merci d'avance pour votre aide.

--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com

Salut,

J'ai un eu du mal à voir ce que tu controles ou pas.

Peux-tu surcharger le modèle de ton JTextPane ? 

En redéfinissant insertString et remove, tu devrais capter
le moment auquel le texte change. Cet appel est effectué par le
EventDispatchThread. 

Ca devrait répondre à ton problème, non ?

Olivier
PS : Le reply envoie directement vers toi. Normal ?

> -----Message d'origine-----
> De : Herve AGNOUX [mailto:herve.agnoux@diaam-informatique.com]
> Envoyé : vendredi 10 mai 2002 11:59
> À : java@u-strasbg.fr
> Objet : frequents rafraichissements asynchrones sur swing
> 
> 
> Bonjour,
> 
> Je reçois des messages type JMS dont j'affiche un résumé sur un 
> JTextPane. (enfin, quand je dis "je", vous aurez compris que c'est pas
> moi, evidemment).
> 
> A chaque fois que "je" mets le Document du JTextPane à jour, je 
> voudrais que le JTextPane scroll vers le bas pour afficher 
> automatiquement le dernier message reçu.
> 
> Pour se faire, j'envoie un scrollRectToVisible sur mon JTextPane et tout
> fonctione bien.
> 
> SAUF que si je le fais directos dans le thread qui a reçu le message
> tout plante : en effet, je suis pas dans le "eventdispatchingthread" et
> j'ai pas le droit.
> 
> Je fais alors un SwingUtilities.invokeLater d'un Runnable, et tout
> fonctionne à merveille.
> 
> Le souci, c'est que chaque fois que je reçois un message je crée un
> nouveau Runnable, et je trouve ça lourdingue. Je voudrais ne scroller
> vers le bas que lorsque c'est vraiment utile, ou bien ne pas donner
> l'ordre de rescroller vers le bas si je l'ai déjà demandé, ou bien ne
> pas créer un nouveau thread à chaque fois...
> 
> Sachant qu'il m'est impossible de savoir à l'avance si j'ai encore des
> messages JMS à recevoir (ou alors j'ai mal lu la doc JMS), que
> pourrais-je faire pour optimiser ce processus ?
> 
> Merci d'avance pour votre aide.
> 
> --
> Sur le Web, tout de suite.
> Herve AGNOUX - diaam informatique
> http://www.diaam-informatique.com
> 

Salut Herve,

Herve AGNOUX:
> Le souci, c'est que chaque fois que je reçois un message je crée un
> nouveau Runnable, et je trouve ça lourdingue.

A priori, tu peux reutiliser toujours le meme Runnable (il te suffit de
mettre ses params a jour).

> Je voudrais ne scroller 
> vers le bas que lorsque c'est vraiment utile, ou bien ne pas donner
> l'ordre de rescroller vers le bas si je l'ai déjà demandé,

Normalement, a chaque fois que tu recois un message, il te faut scroller
mais tu peux toujours mettre un tampon avec un delai.

Sinon tu peux connaitre le rectangle visible avec getExtentSize(), 
getViewPosition() et getViewSize().

> ou bien ne 
> pas créer un nouveau thread à chaque fois...

SwingUtilities.invokeLater ne cree pas de thread (il utilise le 
dispatchEventThread).

> Sachant qu'il m'est impossible de savoir à l'avance si j'ai encore des
> messages JMS à recevoir (ou alors j'ai mal lu la doc JMS), que
> pourrais-je faire pour optimiser ce processus ?

Un tampon (Vector accumulant les messages) + un Timer pour demander le
defilement 1 sec apres. (le timer t'evite de creer un thread cf:
http://www.desnoix.com/guillaume/articles/lmf37/ )

Guillaume

Le 10 May 2002 OLIVIER CAYRON a écrit :

> 
> En redéfinissant insertString et remove, tu devrais capter
> le moment auquel le texte change. Cet appel est effectué par le
> EventDispatchThread. 
> 

Non je ne peux pas faire ça parce que, une fois n'est pas coutume, 
j'applique consenscieusement le modèle MVC, et donc depuis le niveau
document je ne sais absolument pas comment il est visualisé.

Je vais plutot suivre la piste donnée par Guillaume, qui m'a l'air 
très pertinente.


> PS : Le reply envoie directement vers toi. Normal ?
> 

Non, pas du tout, mais c'est de ma faute, ou plutot de celle de mon 
logiciel de mail dont les versions récentes sont moins pratiques que les
plus anciennes. Dés que je trouve un logiciel de mail sympa et valable sur
linux, hop ! je change de logiciel de mail.

(en attendant, merci de rediriger mes messages vers la liste lorsque
j'oublie de le faire).

Cordialement.

--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com

> -----Message d'origine-----
> De : Herve AGNOUX [mailto:herve.agnoux@diaam-informatique.com]
> Envoyé : vendredi 10 mai 2002 15:10
> À : java@u-strasbg.fr
> Objet : RE: frequents rafraichissements asynchrones sur swing
> 
> 
> Le 10 May 2002 OLIVIER CAYRON a écrit :
> 
> > 
> > En redéfinissant insertString et remove, tu devrais capter
> > le moment auquel le texte change. Cet appel est effectué par le
> > EventDispatchThread. 
> > 
> 
> Non je ne peux pas faire ça parce que, une fois n'est pas coutume,
> j'applique consenscieusement le modèle MVC, et donc depuis le niveau
> document je ne sais absolument pas comment il est visualisé.

Là, je ne suis pas du tout d'accord avec toi. MVC ne veut pas dire que tu
ne peux pas avoir de lien entre ton modèle et ton affichage. 

Sinon, à quoi servent les fireXXX ?

Si je ne m'abuse, dans le MVC, il y a bien communication entre les
différentes composantes du modèle, non ? Je ne me souviens pas
que les messages soient unidirectionnels ? Ton modèle à le droit
de changer aussi, non ?

Pourquoi n'aurais-tu pas le droit d'améliorer cette communication 
avec tes propres messages du modèle vers la vue (faute de controleur) ?

> 
> Je vais plutot suivre la piste donnée par Guillaume, qui m'a l'air très
> pertinente.

C'est toi qui choisis. :o)

Olivier

> 
> 
> > PS : Le reply envoie directement vers toi. Normal ?
> > 
> 
> Non, pas du tout, mais c'est de ma faute, ou plutot de celle de mon
> logiciel de mail dont les versions récentes sont moins pratiques que les
> plus anciennes. Dés que je trouve un logiciel de mail sympa et valable
> sur linux, hop ! je change de logiciel de mail.
> 
> (en attendant, merci de rediriger mes messages vers la liste lorsque
> j'oublie de le faire).
> 
> Cordialement.
> 
> --
> Sur le Web, tout de suite.
> Herve AGNOUX - diaam informatique
> http://www.diaam-informatique.com
> 

Le 10 May 2002 OLIVIER CAYRON a écrit :

> 
> Là, je ne suis pas du tout d'accord avec toi. MVC ne veut pas dire que
> tu ne peux pas avoir de lien entre ton modèle et ton affichage. 
> 

Je me suis mal exprimé, il y a bien un lien du modèle vers 
l'affichage, simplement le modèle ne sait pas quel est le type 
d'affichage.

En l'occurence il s'agit d'une partie javax.swing.text ; j'ai un 
Document comme modèle, et l'affichage (un JTextPane dans un 
JScrollPane) s'est abonné auprès du Document pour écouter les modifs sur
ce document.

Donc, de l'affichage, le Document ne connait qu'un ListenerDocument. C'est
un peu short pour qu'il commande la portion du scroll à afficher. De plus
il pourrait très bien y avoir plusieurs ListenerDocument abonné à mon
Document, sans que ce dernier sache lequel exactement s'occupe de la vue.

C'est donc mon ListenerDocument qui commande le scroll, et non 
directement le Document.


> 
> Si je ne m'abuse, dans le MVC, il y a bien communication entre les
> différentes composantes du modèle, non ? Je ne me souviens pas que les
> messages soient unidirectionnels ? Ton modèle à le droit de changer
> aussi, non ?
> 

Il y a communication, mais sans que les parties sachent exactement la
nature des uns et des autres. Par exemple un Document peut être visualisé
par un JTextPane, et quantité d'autres Components. Ce component peut être
dans un JscrollPane, ou ne pas y être, etc.

Il y a juste une interface entre les deux. (je suis en train de 
découvrir le "Thinking in Patterns with Java" de Bruce Eckel, 
http://www.MindView.net, et je me demande s'il s'agit d'une "Facade", d'un
"Adapter", ou de quelques autres subtilités passionnantes :-).


> Pourquoi n'aurais-tu pas le droit d'améliorer cette communication avec
> tes propres messages du modèle vers la vue (faute de controleur) ?
> 

Sur ce coup là cela ne m'intéresse pas. Je ne sais pas encore quel 
"Document" je vais utiliser, et donc je voudrais rester le plus 
"swing standard" possible. (... mais peut être qu'en utilisant le 
pattern du "decorator" je pourrais être plus fin ?... )

A+.


--
Sur le Web, tout de suite.
Herve AGNOUX - diaam informatique
http://www.diaam-informatique.com

>
>Il y a juste une interface entre les deux. (je suis en train de
>découvrir le "Thinking in Patterns with Java" de Bruce Eckel,
>http://www.MindView.net, et je me demande s'il s'agit d'une "Facade",
>d'un "Adapter", ou de quelques autres subtilités passionnantes :-).

en gros une facade  sert a centraliser des services disparates  (proposes
dans plein de composants differents) de maniere a etre l'interlocuteur
unique d'un client... un adapter sert a 'bricoler' un composant de maniere
a ce qu'il aparaisse comme ayant la meme interface qu'un autre... cf le
bouquin du GoF pour de plus amples infos...

Jerome