Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Line breaks
Message
De
28/01/2015 13:15:41
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Titre:
Versions des environnements
Visual FoxPro:
VFP 9 SP2
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01614431
Message ID:
01614526
Vues:
48
>>I know there a countless alternate ways of doing this but is there a way to display line breaks tucked inside a memory variable displayed in a window
>>I suspect it's one of those 'filetostr strtofile conversions' but i'm having trouble with the syntax
>>thanks for your help
>>
>>mes = 'I need the line break'+chr(13)+'To be displayed in this window'+chr(13)+'any suggestions??'
>>activate window temp
>>? mes  &&& all I get here is 'any suggestions'
>>
>
>Don't use ? to output message. Use messagebox. Also, you may want to try chr(13) + chr(10) instead of just chr(13).

To further explain what's going on, CHR(13) is what is called a "carriage return" and CHR(10) is what is called a "line feed" -- basically to explain it in terms of a dot-matrix or inkjet printer, "carriage return" moves the print head to the beginning of the line, and "line feed" advances the paper by one (text) line. Depending on the context in which you use these characters, the interpretation differs. Under Unix system, the linefeed character alone was used to indicate "newline" (advance to next line, starting at beginning of line), whereas in DOS the linefeed would simply advance to the next line (so the next character printed would start just below and to right of the previous character). When outputting using ? / ?? the interpretation follows the DOS convention, while either carriage return or linefeed alone would be sufficient to get "newline" when outputting using MESSAGEBOX().
Although visually carriage return followed by linefeed is indistinguishable from linefeed followed by carriage return, having the characters reversed could result in potentially weird behavior -- usually with text editors. In some cases the text editor would "eat" (i.e. remove) character following the carriage return (assuming that it was a linefeed), and others might "eat" (i.e. remove) the character preceding the linefeed (assuming that it was a carriage return) -- meaning that if you had a file with carriage return and linefeed in reverse order, you sometimes lost either the first character of each line starting from the second line, or lost the last character on each line except for the last line.
One the methods we often used back in the old days to perform overstriking on printers to get stuff like boldface, strikethrough, underline, or to simply "compose" or combine characters, one often used carriage return. This allows you to print the text, then use carriage return to move the print head to the beginning of the line. Although backspace could be used, usually print head movement was often inaccurate if you tried to move the print head incrementally in the reverse direction -- mostly due to the particulars of the mechanism -- usually in most mechanical systems there is usually some backlash (i.e. "slop" or "play") in the mechanism. This is one of the reasons on many dot-matrix printers there was a unidirectional mode you can engage -- it was slower, but lines would be better aligned, whereas bidirection mode was generally faster, but you often ended up zig-zag columns of text.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform