I've got a multiline input text field into which a user can enter up to 1200 characters

but when the user file is passed to the XML -> db for later retrieval, i lose the line breaks ...

I thought about having the ENTER key return a \n value, but that would write it (visibly) to the text field - and that seems kinda chintzy.

any suggestions on how to resolve this (AS3)?

In XML, the proper character to use for agnostic line breaking in a content node is UTF-8 & #xD;

remove the space between the ampersand and the hash. :P

This character is used to allow different systems to convert linebreaks to native linebreak characters on different systems.

To convert your output, run an escape on the field text value, then do a find replace on the string before you POST the data from the client app. The user never need see this conversion ever.

var normalizedBreakString = escape(rawInputFieldonTheUI.text).split("%0D").join("& #xD;");

remember to remove the space between the ampersand and the hash. :P

You can send this character right back to Flash from the DB in XML without converting it back to /n because the Flash xml parser will do the work for you since this must be supported to meet w3c XML spec.

If you have HTML enabled in the input field, this will be a different matter.

You'll hear advice to use br tags and CDATA. don't. its noobish. Your linebreaks as they are now are being ignored because we use them in XML to write XML with human readable breaks, so it ignores them also in content, literally removing them before parsing the XML document. The truly beautiful and powerful advantage of & #xD; is that it can be used in an XML attribute

another gem from persist there - thanks for the tip

would I be able to add the escape(rawInputFieldonTheUI.text).split("%0D").join("& #xD;"); to the existing function for the 'submit' button?

or will I need to create a function to action the var and call the function from the 'submit' button function?

You should be able to put it right in the submit.

post the function.

function closeAndAddInputText(e:MouseEvent):void { currentSlideText.slideTextHolder = textBox.inputTB.text; closeInputText(e); trace("saved"); escape(textBox.inputTB.text).split("%0D").join("&_#xD;"); }

Thats confusing but it should work like this I think:

function closeAndAddInputText(e:MouseEvent):void { currentSlideText.slideTextHolder = escape(textBox.inputTB.text).split("%0D").join("&_#xD;"); closeInputText(e); trace("saved");

}

would component textArea behave any differently that an input textField?

and is there any way to trace the output to determine if the problem is with what i'm sending or what i'm retrieving?

would .NET be the culprit that is truncating the string at the first '&'?

can you open the .net script that produces your XML directly in the browser?

If the script needs to have some params passed in to produce the XML, manually enter them into the .net code and then run it to see if it's producing good XML.

Have a look at what is being sent/recieved using Firefox Live HTTP headers / Firebug, or better, Charles Debugging Proxy

I doubt that .NET would break at the ampersand. That in my experience has always been Flash borking.

wanted to save thanks for everybody's assistance with this one - never been so frustrated by a string of data in my life ...

since we were sending multiple unique data chunks, the '&' was borking the outbound stream - solution was simply to 'escape' the outbound string and 'unescape' on the inbound ... of course coming to this conclusion required multiple trips to the ends of the earth and back, but it works now - and i guess that's ultimately the important thing.

so if i understand, 'escape' allows the URL encoded string to pass as-is ... and 'unescape' converts it back to its original content as generated by Flash?

That is pretty much correct.

Escape URLencodes the string; unescape decodes it.

I guess the XML was probably breaking on a attribute or node that had an ampersand in the value - this is an easy fix for nodes (use CDATA tags) , and not so hard to escape the attribute value if that has an ampersand.

Either way, an ampersand in an attribute or in a node's value would break - going in, or out of - pretty much any XML-based system.

CDATA has been my friend since I learnt the hard way 5 or 6 years ago.

you know i tried <!CDATA> - but was unable to save the outbound string - it eventually just timed out

had the same problem when experimenting with changing line breaks to tags - i assumed that it was trying to read the < as the beginning of an XML tag and just borked the string

i've used CDATA successfully before - but only when sending simple, single packet strings - any idea what might have caused the probs this time?