Re: [ConvertChars] problem
This WebDNA talk-list message is from 1997
It keeps the original formatting.
numero = 12722
interpreted = N
texte = >I think I may have found an inconsistency in the way WC works. When I >submit a form, then carry those fields over to the next template, the >[Convertchars] does not convert the carriage returns to
(though it >does convert other characters, such as ©) > >However, if I wrap a [Search] context around it, so the information is >being received from the database rather than directly from the form, it >does convert the carriage returns to
. > >Is there a reason this works this way?Yes. When you display those fields from within a [Search] you aree guaranteeing that the text is coming from a database. WebCatalog converts hard returns (13) to soft returns (11) when it saves text in a database. When you pull those fields back out of the database and use ConvertChars, it changes the (11) to
.On the other hand, when you simply display fields from a form, the characters come through unchanged, which means all the hard returns are still (13). Since there is no default character conversion for (13), the
doesn't show up.If you like, you can add a 13 to your list of character conversions in WebCatalog Prefs. Make sure you quit WebCatalog before making those changes.Grant Hulbert, V.P. Engineering | ===== Tools for WebWarriors ===== Pacific Coast Software | WebCatalog Pro, WebCommerce Solution 11770 Bernardo Plaza Court | SiteEdit Pro, SiteCheck, PhotoMaster San Diego, CA 92128 | SiteGuard 619/675-1106 Fax: 619/675-0372 | http://www.smithmicro.com
Associated Messages, from the most recent to the oldest:
>I think I may have found an inconsistency in the way WC works. When I >submit a form, then carry those fields over to the next template, the >
[convertchars] does not convert the carriage returns to
(though it >does convert other characters, such as ©) > >However, if I wrap a
[search] context around it, so the information is >being received from the database rather than directly from the form, it >does convert the carriage returns to
. > >Is there a reason this works this way?Yes. When you display those fields from within a
[search] you aree guaranteeing that the text is coming from a database. WebCatalog converts hard returns (13) to soft returns (11) when it saves text in a database. When you pull those fields back out of the database and use ConvertChars, it changes the (11) to
.On the other hand, when you simply display fields from a form, the characters come through unchanged, which means all the hard returns are still (13). Since there is no default character conversion for (13), the
doesn't show up.If you like, you can add a 13 to your list of character conversions in WebCatalog Prefs. Make sure you quit WebCatalog before making those changes.Grant Hulbert, V.P. Engineering | ===== Tools for WebWarriors ===== Pacific Coast Software | WebCatalog Pro, WebCommerce Solution 11770 Bernardo Plaza Court | SiteEdit Pro, SiteCheck, PhotoMaster San Diego, CA 92128 | SiteGuard 619/675-1106 Fax: 619/675-0372 | http://www.smithmicro.com
Grant Hulbert
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
shipping with weigth (1998)
Date Question (2002)
[ReturnRaw] and hiding FORM data (2003)
WebCatalog Help (2002)
Hiding my Source Code with W* (2000)
Formulas.db + Users.db (1997)
[WriteFile] problems (1997)
For those of you not on the WebCatalog Beta... (1997)
Bad cookie (1998)
Help! WebCat2 bug (1997)
Re[3]: Problem with new formvariables (2000)
calculating tax rates, mail order solutions and version 2 (1997)
[time] math Q (2003)
404 error -- but wc code executes... (2001)
Include a big block of text (1997)
question: webmerchant connection (1997)
search comparison problem (2000)
Security Issues and WebCommerce Solution (1997)
Don't tick me off :) [elaspedtime] (1997)
Opinion: [input] should be called [output] ... (1997)