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:
E-Mail (1998)
Can't load tmpl files (1997)
SKU lookup (1997)
time and welcome (1999)
Multiple Items (2004)
ShowNext Context (2004)
MacAuthorize and WebMerchant (1997)
Use of Back and Reload Buttons on ShoppingCart page? (1997)
Selective Searching (2000)
searching illegal HTML (2002)
Emailer program? (2000)
What the *(**&^* webcat/mer (1998)
Shipcost formula (2004)
quantity minimum problem (1997)
Uh...can someone help me out with the b10? (1997)
[ShowNext] (1997)
different ship dates and shopping carts -- how to? (1997)
Banners (1997)
WebCat2final1 crashes (1997)
Hiding HTML and page breaks (1997)