Bonjour, Je te remercie de ta r�ponse qui me fait progresser dans ma r�flexion. Comme tu en as mis l'hypoth�se, aujourd'hui on ne vide pas le JTextArea, d'ou l'id�e sous-jacente de limite est int�ressante, comment conna�tre cette limite (taille de texte limite)??
Quelques constatations : L'alimentation socket se fait pour 2 JTextArea de notre application, pour chaque ligne, j'ai pu constater une diff�rence entre les deux : ils se grisent pas en m�me temps. (on peut m�me avoir un temps assez long entre les deux). Salah. Nicolas Delsaux a �crit : > >Bonsoir, > > > >je travail sur le "JDK 1.1.8" sur une station SUN (Solaris 2.7). > >c'est un JTextArea qui s'alimente par un flot de donn�es. Aujourd'hui ce > >JTextArea est aliment� par une socket mais en avait le > >m�me probl�me lorsqu'on alimentait ce JTextArea � partir d'un fichier r�ponse. > >On constate le probl�me al�atoirement, au bout d'un certain tempo, le JTextArea > >se grise en background pendant un temps al�atoire avant de revenir � la couleur > >d'origine (avec phases r�p�titives du ph�nom�ne ). > >Des la r�ception d'une ligne sur le buffer on concat�ne cette ligne � ce qui > >exist d�j� dans le JTextArea. > > /// code > > textSpy.append(inputLine); > > textSpy.setCaretPosition(textSpy.getText().length()); > > textSpy.revalidate(); > >/// code > > > >la lecture du buffer de r�ception est p�riodique (toutes les 300 ms environ). > >cette surveillance est effectu� par un thread. Lorsque l'on a plusieurs lignes � > >surveiller, on a autant de threads que de lignes. > > > >J'ai r�alis� une maquette alimentant en permanence et de fa�on p�riodique un > >JTextArea. et dans ce cas simple, je reproduis ce ph�nom�ne, la lecteure > >p�riodique est effectu�e par un thread. > > > >l'autre manip, c'est de changer la version de JDK passer en JDK1.2 sur SUN. > > > >A l'avance merci, de m'indiquer quelques pistes. > > Je peux me tromper, mais je n'ai vu nulle part de code vidant le textArea lorsqu'il >est trop gros. Or, avec ce type de composant, c'est une pr�caution assez >indispensable � prendre : plus tu auras de txte dans ta zone de texte, plus le >rafra�chissement sera long lorsque tu ajouteras du nouveau texte. > Dans l'application que mon entreprise d�veloppe actuellement, nous avons une >pseudo-console qui capture System.out et System.err. Or, cette pseudo-console risque >elle aussi des d�bordements de m�moire lorsque le texte est trop gros. Il a donc >fallu mettre en place un bout de code qui teste la taille du texte contenu et qui, >s'il est plus gros que la taille limite, le coupe pour ne garder que la fin. > Car apr�s tout, je ne pense pas que tu aies int�r�t � conserver dans ton application >tous tes messages, mais seulement les n derniers, n'est-ce pas ? > > Enfin, tout cela n'est valable que si tu �cris beaucoup de texte dans ton textArea. > Par ailleurs, si c'est possible, pourrais-tu envoyer sur la liste le code >*significatif* de ta maquette (uniquement le code d'alimentation du TextArea) ? > > > >WEB, FAQ, .... > > -- > Nicolas Delsaux > "Ia d�mocratie est la pire des dictatures parce qu'elle est la dictature exerc�e par >le plus grand nombre sur la minorit�." > Pierre Desproges
