Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Debugger bug
Message
De
07/11/2013 12:25:59
 
 
À
07/11/2013 08:55:43
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Titre:
Versions des environnements
Visual FoxPro:
VFP 5
OS:
Windows Server 2012
Network:
Windows 2008 Server
Database:
MS SQL Server
Application:
Web
Divers
Thread ID:
01587352
Message ID:
01587511
Vues:
54
>When the window pops up, you should see only consistent line characters throughout the file, such as nothing but matched pairs of 0D,0A repeated throughout. If it ever changes or shifts, then you likely have some non-standard line endings which is causing the problem.

Ah yes... I'd come across the occasional text file with mangled newline. Somewhat dependent on what text editor was being used. I'd seen mixture of CR (carriage return - 0xD) followed by LF (linefeed - 0xA), LF only, CR only and LF preceding CR. Depending on how the text editor you're using reads these you can get further mangling. Most text editors can be used to "fix" these -- though there may be consequences due to built-in assumptions about newline sequences. The most destructive would be assumption that CR would always be followed by LF -- in cases where this assumption doesn't hold you lose the first character of a line following a CR-only newline. A newline where CR and LF were reversed would often result in "double-spacing" -- annoying but much less disruptive.

With regards to "non-standard" characters -- characters outside of the usual 7-bit ASCII range could be problematic. Generally it is best to avoid character literals using such characters (i.e. avoid situation where you're entering characters by ALT-nnn keyboard sequence). Interpretation of these characters could change according to code page, so they might not be consistently displayed. In Asian-language environment, some of these character values in 128-255 range are used as "lead-in" characters of a two-byte sequence (and thus in Asian-language environment, the following character sometimes gets "eaten" as a result). This could result in situations where a program would work OK in English-language, but get seemingly inexplicable errors when run in Asian-language environment (quite often the ending quote of a string literal gets "eaten", resulting in what looks like you forgot to terminate the string literal in the code). Definitely easier to spot in PRG code, and much harder to spot in SCX, FRX and LBL files (unless you run your development environment in the target environment).
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform