Re: Displaying text and populating form fields
This WebDNA talk-list message is from 2005
It keeps the original formatting.
numero = 61175
interpreted = N
texte = >Ken mentioned: > >To display text on the page from a textarea formvariable --> >use [grep search=%0B&replace=
] > >This would cover many of you but you have to remember that >returns may be different depending on your situation/platform. >You may find that you will need to convert the %0D instead of >the %0B or %OA for example: >[grep search=%0D&replace=
][thetext][/grep] Hi Donovan, Good point, thanks for identifying this mistake. I thought I had tested this properly but it seems I screwed up somehow, and this is one reason why I was hoping that others would help me to resolve this issue, so thanks for your comments and suggestions. Now here's what I learned after doing another test, as you can see I have provided the code for my test as well as the results: Post this data via textarea field to the next page: abc " " " def ghi jkl """end. On the next page use these four contexts: fvconvertchars=[convertchars][a][/convertchars]
fvgrepcr=[grep search=%0D&replace=
][a][/grep]
fvgreplf=[grep search=%0A&replace=
][a][/grep]
fvgrepvt=[grep search=%0B&replace=
][a][/grep]
Then observe the results as follows: fvconvertchars=abc " " " def ghi jkl """end. fvgrepcr=abc " " " def ghi jkl """end. fvgreplf= abc " " " def ghi jkl """end. fvgrepvt=abc " " " def ghi jkl """end. I ran this test on Mac and Windows (but not *nix) and all tests confirmed the same results. The ONLY correct code in these examples is the one labeled "fvgrepcr", so clearly I was wrong when I posted my grep code with "%0B" because it is actually supposed to be "%0D" that works in this situation. After seeing these results I created a "convert.db" that looks like this: from
to %0D
Then I tested this and as expected it produced the same results as the "fvgrepcr" grep code above. This leads me to believe that if we add a "%0D
" record to our StandardConversions.db files this may be the best way to deal with the problem of displaying text properly on the page. Then we can use the default [convertchars] context without a special database, not only when the value comes from a db field, but also when it comes from the textarea field. HOWEVER: I did not test any of this on a *nix computer because I don't have one here, but it seems like it might create a problem for our Windows visitors if we add "%0A
" to our StandardConversions.db because then our Windows visitors will have both their s and their s converted to
s which means they will see DOUBLE SPACING in their browsers ... right? So once again, the bottom line goal here is to find a single solution that works on ALL VISITOR PLATFORMS. Does anyone have a suggestion -- short of detecting the platform and using different code with *nix visitors? Please note that I have not tested whether or not adding "%0A
" to the StandardConversions.db will actually create double line spacing on Windows browsers, but it seems like it would -- unless the browser does some character conversions of its own, and i don't think browsers do this, do they? Maybe we need to test this first to see what actually happens before making any assumptions here ... -- Sincerely, Kenneth Grome www.kengrome.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
>Ken mentioned: > >To display text on the page from a textarea formvariable --> >use [grep search=%0B&replace=
] > >This would cover many of you but you have to remember that >returns may be different depending on your situation/platform. >You may find that you will need to convert the %0D instead of >the %0B or %OA for example: >[grep search=%0D&replace=
][thetext][/grep] Hi Donovan, Good point, thanks for identifying this mistake. I thought I had tested this properly but it seems I screwed up somehow, and this is one reason why I was hoping that others would help me to resolve this issue, so thanks for your comments and suggestions. Now here's what I learned after doing another test, as you can see I have provided the code for my test as well as the results: Post this data via textarea field to the next page: abc " " " def ghi jkl """end. On the next page use these four contexts: fvconvertchars=[convertchars][a][/convertchars]
fvgrepcr=[grep search=%0D&replace=
][a][/grep]
fvgreplf=[grep search=%0A&replace=
][a][/grep]
fvgrepvt=[grep search=%0B&replace=
][a][/grep]
Then observe the results as follows: fvconvertchars=abc " " " def ghi jkl """end. fvgrepcr=abc " " " def ghi jkl """end. fvgreplf= abc " " " def ghi jkl """end. fvgrepvt=abc " " " def ghi jkl """end. I ran this test on Mac and Windows (but not *nix) and all tests confirmed the same results. The ONLY correct code in these examples is the one labeled "fvgrepcr", so clearly I was wrong when I posted my grep code with "%0B" because it is actually supposed to be "%0D" that works in this situation. After seeing these results I created a "convert.db" that looks like this: fromto %0D
Then I tested this and as expected it produced the same results as the "fvgrepcr" grep code above. This leads me to believe that if we add a "%0D
" record to our StandardConversions.db files this may be the best way to deal with the problem of displaying text properly on the page. Then we can use the default [convertchars] context without a special database, not only when the value comes from a db field, but also when it comes from the textarea field. HOWEVER: I did not test any of this on a *nix computer because I don't have one here, but it seems like it might create a problem for our Windows visitors if we add "%0A
" to our StandardConversions.db because then our Windows visitors will have both their s and their s converted to
s which means they will see DOUBLE SPACING in their browsers ... right? So once again, the bottom line goal here is to find a single solution that works on ALL VISITOR PLATFORMS. Does anyone have a suggestion -- short of detecting the platform and using different code with *nix visitors? Please note that I have not tested whether or not adding "%0A
" to the StandardConversions.db will actually create double line spacing on Windows browsers, but it seems like it would -- unless the browser does some character conversions of its own, and i don't think browsers do this, do they? Maybe we need to test this first to see what actually happens before making any assumptions here ... -- Sincerely, Kenneth Grome www.kengrome.com ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Kenneth Grome
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:
DON'T use old cart file! (1997)
[WebDNA] ONLY the FIRST continuous run of numeric chars? (2008)
WebCat/CyberStudio Compatibility (1998)
WebCatalog2 Feature Feedback (1996)
Multi-Row Tables from a search. (1997)
Strange database format import (2000)
Running 2 two WebCatalog.acgi's (1996)
Display [price] in banner ad (1998)
groups and [ShowNext] (1997)
[searchString] (1997)
Separate SSL Server (1997)
[Sum] function? (1997)
Re[2]: OT: Sending email to lots of subscribers (1999)
about this server and links to who (1997)
Document Contains No Data! (1997)
WebCat2 - Getting to the browser's username/password data (1997)
What am I missing (1997)
CAPTCHA system in webDNA (2005)
Snake Bites (1997)
How Many SKU's is enough? (1997)