IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Langage Delphi Discussion :

TRichEdit avec retour chariot non souhaité et bizarrerie de suppression


Sujet :

Langage Delphi

  1. #1
    Membre confirmé

    Inscrit en
    Novembre 2002
    Messages
    744
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 744
    Points : 500
    Points
    500
    Par défaut 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
    Bye et bon code...

    Ce n'est pas tant l'aide de nos amis qui nous aide , mais notre confiance dans cette aide .

  2. #2
    Membre régulier
    Homme Profil pro
    Analyse système
    Inscrit en
    Mai 2013
    Messages
    190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Analyse système
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2013
    Messages : 190
    Points : 113
    Points
    113
    Par défaut
    Salut petitcoucou31,

    C'est très étrange j'ai quand même fais le test chez moi (Delphi XE8, W10), un simple fichier txt :
    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 ?

  3. #3
    Membre confirmé

    Inscrit en
    Novembre 2002
    Messages
    744
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 744
    Points : 500
    Points
    500
    Par défaut
    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.
    Fichiers attachés Fichiers attachés
    Bye et bon code...

    Ce n'est pas tant l'aide de nos amis qui nous aide , mais notre confiance dans cette aide .

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    322
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Janvier 2009
    Messages : 322
    Points : 310
    Points
    310
    Par défaut
    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+

  5. #5
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    Juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 53
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Juin 2004
    Messages : 2 932
    Points : 3 565
    Points
    3 565
    Par défaut
    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".
    Bidouilleuse Delphi

  6. #6
    Membre confirmé

    Inscrit en
    Novembre 2002
    Messages
    744
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 744
    Points : 500
    Points
    500
    Par défaut
    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.
    Bye et bon code...

    Ce n'est pas tant l'aide de nos amis qui nous aide , mais notre confiance dans cette aide .

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    322
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Janvier 2009
    Messages : 322
    Points : 310
    Points
    310
    Par défaut
    Citation Envoyé par sgmsg Voir le message
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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 Voir le message
    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?

  8. #8
    Membre confirmé

    Inscrit en
    Novembre 2002
    Messages
    744
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 744
    Points : 500
    Points
    500
    Par défaut
    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.
    Bye et bon code...

    Ce n'est pas tant l'aide de nos amis qui nous aide , mais notre confiance dans cette aide .

  9. #9
    Membre averti
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    322
    Détails du profil
    Informations personnelles :
    Localisation : Canada

    Informations forums :
    Inscription : Janvier 2009
    Messages : 322
    Points : 310
    Points
    310
    Par défaut
    Bon j'ai fait le petit prog
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  10. #10
    Membre expert
    Avatar de LadyWasky
    Femme Profil pro
    Inscrit en
    Juin 2004
    Messages
    2 932
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 53
    Localisation : France, Hauts de Seine (Île de France)

    Informations forums :
    Inscription : Juin 2004
    Messages : 2 932
    Points : 3 565
    Points
    3 565
    Par défaut
    Faut pas chercher plus loin, c'est un problème d'encodage de caractères !
    Bidouilleuse Delphi

  11. #11
    Modérateur
    Avatar de tourlourou
    Homme Profil pro
    Biologiste ; Progr(amateur)
    Inscrit en
    Mars 2005
    Messages
    3 844
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 61
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Biologiste ; Progr(amateur)

    Informations forums :
    Inscription : Mars 2005
    Messages : 3 844
    Points : 11 274
    Points
    11 274
    Billets dans le blog
    6
    Par défaut
    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 ?
    Delphi 5 Pro - Delphi 10.4 Rio Community Edition - CodeTyphon 6.90 sous Windows 10 ; CT 6.40 sous Ubuntu 18.04 (VM)
    . Ignorer la FAQ Delphi et les Cours et Tutoriels Delphi nuit gravement à notre code !

  12. #12
    Membre confirmé

    Inscrit en
    Novembre 2002
    Messages
    744
    Détails du profil
    Informations forums :
    Inscription : Novembre 2002
    Messages : 744
    Points : 500
    Points
    500
    Par défaut
    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
    Bye et bon code...

    Ce n'est pas tant l'aide de nos amis qui nous aide , mais notre confiance dans cette aide .

Discussions similaires

  1. Réponses: 5
    Dernier message: 12/11/2014, 23h39
  2. Format Text avec retour chariot
    Par Poisson59 dans le forum MS SQL Server
    Réponses: 1
    Dernier message: 18/01/2007, 14h34
  3. Export champ 'text' avec retour chariot
    Par wizdom dans le forum MS SQL Server
    Réponses: 6
    Dernier message: 22/09/2006, 17h02
  4. decompte avec retour chariot
    Par taka10 dans le forum Général JavaScript
    Réponses: 8
    Dernier message: 23/08/2006, 16h31
  5. afficher texte avec retour chariot aprèq requète sql
    Par frenchy371 dans le forum Requêtes
    Réponses: 2
    Dernier message: 07/01/2004, 18h33

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo