Discussion :

[Pedro]

Salut à tous
J'ai quelques questions sur CR/LF:
- c'est #10#13 ou #13#10? Je vois une version différente dans plein de posts...
- Est-que mettre Chr(vk_Return) renvoie exactement la même chose?
Merci d'avance

[MD Software]

CR = #13
LF = #10

que tu fasses l'un ou l'autre, c'est pareil, l'ordre n'a pas d'importance.

Chr(vk_Return) est particulier, et essentiellement adapté aux compatibilités entre plate-forme. Sous windows, il fait la même chose.

[Pedro]

Je te remercie bien

[Mac LAK]

CR = #13
LF = #10

que tu fasses l'un ou l'autre, c'est pareil, l'ordre n'a pas d'importance.

Chr(vk_Return) est particulier, et essentiellement adapté aux compatibilités entre plate-forme. Sous windows, il fait la même chose.

HEIN ???? Non, ce n'est PAS la même chose !!!
"CR/LF", c'est #13#10 et PAS LE CONTRAIRE : il existe pas mal de protocoles qui requièrent que les deux caractères soient dans cet ordre, les plus connus sont (au hasard) Telnet, FTP, HTTP, SMTP, etc...

[MD Software]

En effet, je parlais juste pour afficher du texte à l'écran ou dans une MessageBox.

[Mac LAK]

Désolé, mais pas plus...

Une paire LF/CR n'est pas "automatiquement" traduite en CR/LF (seule paire "valide" sur un système DOS/Windows), et suivant le cas, cela peut même provoquer des dysfonctionnements "amusants", notamment lors de la redirection de la console ou pour certains logs de journal.

CR/LF, ce n'est pas LF/CR.

[MD Software]

cela peut même provoquer des dysfonctionnements "amusants", notamment lors de la redirection de la console ou pour certains logs de journal.

Sérieux ?

Je savais pas. Alors j'ai rien dit. Je ne me suis jamais retrouvé devant ce problème.

En tout cas, c'est bon à savoir.

[Mac LAK]

Sérieux ?

Oui : certains programment cherchent activement la combinaison "CR/LF" dans cet ordre et s'en servent comme terminateur de ligne... Comme ils ne trouvent pas, tu te retrouves avec une "ligne" de quelques... mégas. :-( Ou une violation d'accès, suivant l'OS. Dans les deux cas, c'est le crash, et l'erreur est franchement méga chi.... à trouver (c'est du vécu, je sais de quoi je parles).

Je savais pas. Alors j'ai rien dit. Je ne me suis jamais retrouvé devant ce problème.

Ben comme les contrôles Delphi effectuent toujours la conversion "correcte" lorsque c'est nécessaire (du moins à ma connaissance), il est rare d'avoir le pépin avec ce langage.
En C, sous DOS par exemple, c'est une autre paire de manches ! :-D
Tu peux aussi avoir le pépin avec certains programmes en ligne de commande "alimentés" par un pipe et/ou un fichier texte, je crois que certains makefiles digèrent mal également.

En tout cas, c'est bon à savoir.

Là, on est d'accord à 100% !!!

[Gilbert Geyer]

Vaut encore mieux de déclarer une fois pour toutes une constante unique qui regroupe les deux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
const FinParagraphe = #13#10;

[Cl@udius]

Salut

Cette constante existe déjà dans l'unit System et est définie ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
const
  sLineBreak = {$IFDEF LINUX} #10 {$ENDIF} {$IFDEF MSWINDOWS} #13#10 {$ENDIF};

[Edit] Il sort d'outre-tombre ce post ! [/edit]
@+ Claudius

[Gilbert Geyer]

Il sort effectivement d'outre-tombe mon post.
Mais merci pour l'info et dommage que cette constante soit nommée "sLineBreak" alors qu'elle agit plutôt comme une fin de paragraphe dans le cas très utilisé des chaines longues.
Le nom des ancêtres était bien plus clair CR = (Carriage-Return) = Retour chariot et LF = (Line-Feed) = Ligne-Suivante ... hérités du temps des machines à écrire d'IBM, préhistoire de la micro-informatique !

Bon on va suivre la mode et l'appeler sLineBreak.