Salut tout le monde,  
 
Je préviens d'abord que je suis un débutant en prog Windows (MFC notamment) et que je suis en train de me mettre à Visual C++ 6.0. Là j'ai créé avec l'aide d'un bouquin un petit programme de chat avec client/serveur (à l'origine il ne pouvait y avoir qu'un client mais j'ai fait en sorte qu'il puisse y en avoir plusieurs).  
 
Je voudrais encore améliorer le programme, parce que celui d'exemple propose en guise de liste de messages un contrôle ListBox : ce qui est chiant, c'est que les messages trop longs ne passent pas à la ligne suivante, et sont donc tronqués.
 
Donc j'ai pensé à le remplacer par un EditBox (en multiline, et en lecture seule, même si j'espère que dans ce cas le fond n'est pas obligatoirement gris). J'ai créé ma variable de type contrôle et tout le tralala.  
 
Mais surprise, il n'y a aucune méthode permettant d'ajouter du texte (!!?). La seule méthode intéressante est SetWindowText(), mais le texte se fout toujours au début et remplace le précédent (pour un EditBox en une ligne ça suffit, mais bon).  
 
N'y a-t-il pas moyen de sélectionner une ligne, puis d'y insérer un texte ?? Je sais pas, ça pourrait servir dans pas mal de prog, mais je vois pas. Si je crée une variable membre texte (CString) pour le contrôle, j'ai la méthode Insert(), mais on ne peut pas insérer du texte à un endroit qui n'a pas déjà de texte (par ex. : la ligne suivante du texte).
 
En gros ce que je veux faire est simple, à chaque message, un truc du genre :
m_ctrlMsgList.SelectLine(i_CurrentLine++);
m_ctrlMsgList.AddText(0, s_String);
(0 indiquant le début de ligne).
 
De + les textes passent automatiquement à la ligne suivante dans une EditBox multiline, ce serait donc parfait.
 
J'ai essayé un RichEditBox (je sais pas trop ce que ça change), j'ai pas vu d'autres fonctions plus intéressantes pour ce que je veux faire, et surtout le programme ne démarre pas en sa présence (??).
 
Voilà, si qqun a une idée, je prends, ça m'aiderait pas mal. Bon chui un newbie alors vous excitez pas si c'est tout con .

[edtdd]--Message édité par Sielfried--[/edtdd]

Il me semble qu'un ListBox est constitué de lignes distinctes donc remplaçables/effaçables/.. une par une tandis qu'un EditBox contient une seule chaîne. Je ne sais pas si le passage à la ligne est automatique sous VC/MFC. En 16 et 32 bits sous BC3/BC5, je crée une chaîne contenant des CrLf (ASCII 10 et 13 (ou 13 et 10, ai un trou)). Ca sert à passer à la ligne et à séparer les "blocs" de texte.
 
Pour changer le contenu, je crains (suis plus newbie mais pas très "rusé" ) qu'il faille réactualiser le texte du contrôle. Ceci, en gérant en externe la chaîne affichée dans le contrôle puis en la lui réappliquant une fois modifiée... Lourd ?
 
szChnList = "toto1CrLftoto2CrLftoto3" affichera
toto1
toto2
toto3
 
en remplaçant "toto2" par "nouveau", ça donnera
toto1
nouveau
toto3.
 
Ai rien de mieux sous le coude....

Bon là je viens de virer la propriété Auto HScroll tout en laissant Multiline, et quand j'écris moi-même dans la boîte à partir du programme lancé je peux par un simple appui sur Entrée passer à la ligne suivante, et il le fait automatiquement lorsque je dépasse la largeur d'une ligne. Donc dans ce cas ça peut être plusieurs chaînes.
 
Donc il me faut maintenant un truc pour passer à la ligne suivante (CrLf n'est pas reconnu sur VC++, faut sûrement un include ?). Un "\n" ne marche évidemment pas, je suppose que c'est réservé aux programmes dos ?
 
Enfin ça ne change rien au fait que je devrais enregistrer à chaque fois tout le texte du chat dans une variable, ce qui est un peu bête. Enfin là j'ai trouvé, ReplaceSel() qui remplace la sélection par un texte donné marche bien (du moment que l'utilisateur ne met pas en surbrillance un quelconque texte, ça le met juste après le texte déjà écrit), arf, c'est quand même laborieux...
 
En tout cas merci pour ton aide   ^^

A condition de lui envoyer le bon message pour dire que la largeur du texte dépasse celle de la fenêtre, on peut scroller horizontalement un ListBox. C'est juste un peu "pénible" à pratiquer...  
 
Je ne me souviens pas si \r\n est efficace dans un EditBox. Ca semble pas, vu le résultat .

Ah ben si, ça marche "\r\n"    
Par contre \n tout seul merde. Tu peux me dire à quoi sert exactement le \r ?
 
Bon, ben en tout cas ça m'arrange bien ! Merci à toi . J'ai maintenant deux solutions : soit enregistrer tout le texte dans un tableau et le réafficher à chaque fois avec SetWindowText(), soit remplacer la variable membre m_ctrlList de type contrôle par une variable CString m_strList, auquel cas je peux utiliser Insert() :  
Insert(m_strList.GetLength(), texte)...
 
Je peux aussi me débrouiller avec ReplaceSel() mais là ça ferait bidouille, j'aime pas trop.
 
Allez merci et ++

Sielfried a écrit a écrit : Ah ben si, ça marche "\r\n"     Par contre \n tout seul merde. Tu peux me dire à quoi sert exactement le \r ?   Bon, ben en tout cas ça m'arrange bien ! Merci à toi . J'ai maintenant deux solutions : soit enregistrer tout le texte dans un tableau et le réafficher à chaque fois avec SetWindowText(), soit remplacer la variable membre m_ctrlList de type contrôle par une variable CString m_strList, auquel cas je peux utiliser Insert() :   Insert(m_strList.GetLength(), texte)...   Je peux aussi me débrouiller avec ReplaceSel() mais là ça ferait bidouille, j'aime pas trop.   Allez merci et ++

 
\r : carriage return : retour au debut de la ligne
\n : new line : pass à la ligne suivante
 
vielle héritage datant des machines à écrire

Sous Linux/Unix, y a que le caractère 10 (0AH) en fin de ligne, dans le monde McIntosh, y a que 13 (0DH). Sous DOS et Windows, il faut les deux (dans le bon ordre).

twixy a écrit a écrit :     \r : carriage return : retour au debut de la ligne \n : new line : pass à la ligne suivante   vielle héritage datant des machines à écrire

 

 
En fait je savais ça, mais quand je programme sous Dos un simple "\n" suffit

CARBON_14 a écrit a écrit : Sous Linux/Unix, y a que le caractère 10 (0AH) en fin de ligne, dans le monde McIntosh, y a que 13 (0DH). Sous DOS et Windows, il faut les deux (dans le bon ordre).

 
C'est bizarre, sous DOS j'ai toujours utilisé "\n" tout court et ça passait au début de la ligne suivante...  

Peut-être que le compilateur, gentil comme il est, le faisait pour l'opérateur, afin de lui épargner de la peine ?  
 
Si y a pas les deux dans un fichier, quand on le lit sous Windows sur PC, ça fait bizarre (il me semble que c'est un moyen (facilement détournable !) pour empêcher de lire les pages html (afficher source) car les lignes s'écrasent les unes les autres à l'écran).
 
Ce qui compte, c'est que ça fonctionne.