TRichEdit avec retour chariot non souhaité et bizarrerie de suppression

Bonjour a tout le monde,

je développe sous W7 et Delphi X2.

J'ai un problème avec le chargement d'un fichier texte dans un Trichedit.
J'ouvre un même fichier avec le blocNote de Windows et la fonction "RichEdit.Line.Loadfromfile" et je n'ai pas le même résultat.

Dans le blocNote tout est ok.
Quand le fichier est ouvert dans un composant "TrichEdit", aléatoirement des lignes vides s’intercales aux lignes réelles.

Je crois avoir déjà vue cela dans des Tmemo par le passé! sans avoir vraiment trouvé la raison.

Le texte du fichier texte est brut, pas de formatage, ni de balise RTF, ni de retour chariot ...

quelqu'un aurait-il une idée ?

merci

Salut petitcoucou31,

C'est très étrange j'ai quand même fais le test chez moi (Delphi XE8, W10), un simple fichier txt :

Citation:

---

ceciceij eijeic oiezci onzoeicnzoenc zioencoinzeocn
ijzeoidj zoeidj zoiedj zoiejd zoiejd oizejdoi zjeoijd
izjedo izjeoidj zoiejdo ziejdoizj oeidj ozijedoij zed
ziejdo zjeo zozozo

---

un RichEdit et ça me retourne mot pour mot la même chose ...

Il contient quoi ton fichier texte, le plus exactement si possible ?

Salut Greg, et les autres.

Ces problèmes semblent liés à la taille des fichiers ???

Donc plus plus d'infos.. j'ai en fait deux problèmes avec des routines basées sur les TRichEdit.

Plutôt que de tous expliquer,je joint le bout de code que j'utilise pour essayer de comprendre les problèmes et bien visualiser les problèmes.

Utilisation: après avoir lancer l'application, une fenêtre s'ouvre avec deux TrichEdit et quelques composants.

1°problème : les lignes vides.
Au lancement, un fichier se charge dans le Richedit2 (celui de droite), c'est un fichier type de l'application en question et ils peuvent être volumineux.
Quand on clique sur le bouton "detecte ligne vide", il scrute le fichier contenu dans le richedit2 et renseigne les numéros de ligne vide dans le combo juste au dessus. Il existe 7 lignes vides pour le fichier fourni, Si on choisi un numéro de ligne dans le combo, elle s''affiche).

Quand on compare avec d'autres éditeurs : NotePad, NotePad++ ,.. eux n'ont pas ces lignes vides contrairement au RichEdit2.


2°problème : les suppressions de lignes.
Le but de la manip étant de faire un filtrage des lignes à imprimer sur demande de l'opérateur, on supprime les lignes en fonction de leur entête(les trois 1er caractères de la ligne). Dans l'exemple fourni on supprime toutes les lignes qui commencent par "DO|". Le but étant de ne plus avoir de ligne commençant par "DO|" dans le fichier. CE traitement se passe dans le TrichEdit1 ( celui de gauche).

1. Cliquer sur le bouton "Filtre ligne" qui n'est là que pour supprimer les lignes vides, on attend la fin du traitement qui prend quelques secondes.
2. définir une valeur du TEdit, cette valeur n'est là que pour changer le nombre de suppression que je souhaite réaliser (debug) en mode réel on traite l’intégralité du fichier en une seule passe.
3. Cliquer sur le bouton "Supprime ligne", en fonction de la valeur du Tedit, cela fonctionne quelque fois:

Si la valeur du Tedit < 200, cela fonctionne pour le début du fichier, et après plusieurs clic sur le bouton "supprime ligne",la suppression ne fonctionne plus.
Si on traite le fichier en entier cela ne fonctionne pas .

L'erreur produite est une décalage des lignes durant le Richedit.Line.delete. On dirait que la suppression ne concerne pas que la ligne sélectionnée.

Il existe bien sur des solutions pour traiter tout cela, filtrages des lignes vides, changement de méthode pour la suppression, ce que j'ai fais. Mais comme ces traitement existent dans beaucoup d'endroits de l'application, Je dois en connaitre la cause pour traiter le problème à la source.

Voila, je suis en attente de vos surjections et merci d'avance.

Lis ton fichier avec un filestream et décortique ton fichier en trouvant les #13#10. (En faisant un petit afficheur hexa de caractères inhabituelle <>['a'..'z','A'..'Z','0'..'9','.',...]

Tu vas trouver la raison exacte de ce qui crée ces lignes mystérieuses.

D'après moi, cela a rapport avec un caractère inférieur à 32 qui se retrouve dans le fichier, peut-être #9 . Peut-être même un mauvaise séquence de #13#10. Par exemple seulement #13, ou #10.

"Officiellement" pour faire un retour à la ligne c'est #13#10.
Si tu n'as que #13 tu as un retour à la ligne mais en écrivant par dessus la ligne précédente. (Delphi se contente de #13 comme retour a la ligne)
Si tu n'as que #10 tu as un saut de ligne mais en poursuivant à la colonne suivante. (Delphi se contente de #10 comme retour a la ligne)

Si tu as une séquence #10#13 tu auras aussi des problèmes.

Ah oui, cela peut-être simplement que si le dernier caractère de la phrase est à la dernière colonne(en position maximum), un retour de ligne est généré. Si tu y ajoutes un retour de ligne, il y aura donc deux retours de ligne. Il faut donc un éditeur un peu plus intelligent que la moyenne pour régler ce problème.

A+

Attention au "retour à la ligne automatique" dans notepad. Ca peut induire en erreur.
Pour avoir le coeur net, tu peux ouvrir ton fichier dans Notepad++ et tu lui demande d'afficher les caractères "cachés".

Merci à vous pour ces idées.

Je me suis aussi penché sur ce problème d'erreurs incluent dans le fichier source (*.res).

Sgmsg , je n'ai pas trouvé d'anomalies qui pourrait être générées, suite l'insertion de caractères pouvant créer des retours en début de ligne ou des retours chariot sans retour à la ligne ...
Et comme le souligne LadyWasky j'ai aussi fait la manip avec le NotePad++. Je n'ai pas encore trouve le courage de dépouiller le fichier dans un éditeur Hexa vue sa taille:?.

Et rien de détectée d'anormal. Les seuls caractères de contrôles sont des "Retour chariot + retour a la ligne" et de la" tabulation".
Quand je regarde (dans le fichier source) plus précieusement à l'endroit ou l'on trouve une ligne rajouté dans le "Richedit", je ne vois aucune anomalie.

Citation:

---

Envoyé par sgmsg

Lis ton fichier avec un filestream et décortique ton fichier en trouvant les #13#10. (En faisant un petit afficheur hexa de caractères inhabituelle <>['a'..'z','A'..'Z','0'..'9','.',...]

---

C'est pas bien long:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

OccurencesDistinctes:=tstringlist.create; OccurencesDistinctes.sorted:=true; OccurencesDistinctes.duplicate:dupignore;   for i: length(texte) do begin if not [texte[i]] in [#9,#10,#13,'a'..'z','A'..'Z','0'..'9','.',...] then begin Od:=texte[i]+'_'+inttostr(ord(texte[i])) if not OccurencesDistinctes.find(Od,x) then begin memo1.lines.add(Od); OccurencesDistinctes.add(Od); end; end;

---

Il ne restera pas grand chose et au fur et à mesure que tu le relances tu ajoutes des caractères à retirer de l'affichage...

Citation:

---

Envoyé par sgmsg

Ah oui, cela peut-être simplement que si le dernier caractère de la phrase est à la dernière colonne(en position maximum), un retour de ligne est généré. Si tu y ajoutes un retour de ligne, il y aura donc deux retours de ligne. Il faut donc un éditeur un peu plus intelligent que la moyenne pour régler ce problème.

---

As-tu regardé ça?

...

As-tu essayer de conserver la phrase avant et après la discontinuité et d'afficher le nouveau fichier? Le mot avant et après la discontinuité, etc?

Re salut Sgmsg,

A la place de ta solution qui est aussi séduisante, j'ai simplement inspecté le fichier texte à l'endroit où j'ai une ligne vide en trop (peut être retour chariot, mais pas sur) avec un éditeur "hexa" pour voir tous les caractères qui s'y trouvent et voir si des caractères pourraient créer ces lignes en trop et le fichier semble toujours correct.

As tu essayé de télécharger le code que j'ai joint à ce post, pour visualiser le fameux fichier. Tu pourra voir que toutes les lignes sont en plus quasi-identiques et tu verra mieux aussi le problème.

Bon j'ai fait le petit prog

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

var OccurencesDistinctes:tstringlist; i,x:integer; contenu,Od:string; const Caracteres:TSysCharSet=[#0,#9,#10,#13,'a'..'z','A'..'Z','0'..'9','.'] ; begin richedit1.lines.text:=''; //l:=tstringlist.create; contenu:=fastreplace(lisfichier(fichier),#0,'');//Enlève le caractère zéro du fichier, sinon je ne peux l'afficher dans un richedit //l.text:=contenu; OccurencesDistinctes:=tstringlist.create; OccurencesDistinctes.sorted:=true; OccurencesDistinctes.Duplicates:=dupignore;   richedit1.lines.text:=contenu;   for i:=1 to length(contenu) do begin if not (contenu[i] in Caracteres) then begin Od:=contenu[i]+'_'+inttostr(ord(contenu[i])); if not OccurencesDistinctes.find(Od,x) then begin richedit1.lines.add(Od); OccurencesDistinctes.add(Od); end; end; end;     OccurencesDistinctes.free;   end;

---

J'ai extrait ceci de non inclus dans Caracteres:TSysCharSet=[#0,#9,#10,#13,'a'..'z','A'..'Z','0'..'9','.']. Rien de bien méchant:

ÿ_255 //une seule occurence
þ_254 //une seule occurence
[_91
]_93
_32
=_61
:_58
\_92
/_47
(_40
)_41
-_45
|_124
°_176
;_59
,_44
é_233
'_39
î_238
§_167
~_126
>_62
{_123
}_125

Dans le richedit je n'ai rien trouvé d'anormale, aucune ligne superflue.

Je l'ai affiché dans notepad, pas trop problématique non plus.

Je ne peux allez plus loin, j'utilise D6 et toi une version beaucoup plus moderne de Delphi. Ton Delphi utilise le codage des caractères sur 16 bits alors que moi c'est 8;

À priori, ça semble être un bug d'affichage. Mais je suis mal placé pour parler...

En passant, si tu utilises le codage sur 8 bits tu gagneras 50% sur la taille du fichier c'est possiblement non négligeable... et cela serait marrant que ça règle ton problème ;)

Faut pas chercher plus loin, c'est un problème d'encodage de caractères !

Le $FFFE en tête, c'est le BOM pour l'endianess ; serait-il possible que le choix du Charset des TRichEdit à ANSI plutôt que OEM ou autre soit fautif ?

Re

Merci sgmsg pour ton temps et aussi autres pour leur intérêt.

L'encodage nous avez aussi interpellé, mon collègue a tenté de changer le "Charset" sans savoir lesquels il a essayer, mais sans succès non plus.

Et même pour l'encodage, quand on voit le fichier texte, 3000 lignes quasi-identiques, si l'encodage était en cause pourquoi cette erreur met autant de temps pour "survenir". Elle ne survient qu'après l’exécution de 2000 lignes de traitement identique sur des lignes ou juste une valeur numérique change (1 à 64) en plein milieu de la ligne. Cela me laisse aussi interrogatif pour l'encodage :?