Here’s yet another really shitty behavior in Windows Forms: If you have a TextBox/EditBox that contains carriage returns that are single CHR(13) or CHR(10)’s, the textbox displays these characters instead of properly translating them into linefeeds.
Now you might say, no big deal – you should be using the appropriate linefeed pairs always anyway and the Textbox itself adds this correctly, but the problem is that if you ever pass data over a Web Service or otherwise encode and decode the data displayed using XML you will find out quickly that all carriage returns get converted into single CHR(10)s. So this is a real problem and as far as I can tell the textbox can’t deal with this directly which makes for some really screwed up displays.
To work around this I decided to take a heavy handed hack and add a property to my EditBox control (which is directly subclassed from wwTextbox which derives from TextBox). In this control I add a property called FixupLinefeeds which turns any single CHR(13) or CHR(10) chars into CHR(13)+CHR(10). Here’s the code that does this:
public class wwEditBox : wwTextBox
{
public wwEditBox()
{
this.AcceptsTab = true;
this.AcceptsReturn = true;
this.Multiline = true;
this.ScrollBars = System.Windows.Forms.ScrollBars.Vertical;
this.Height = 100;
this.Width = 250;
this.MaxLength = 99999999;
}
///
/// Determines whether the field can be left blank. If left blank a binding error
/// is created and rendered.
///
[Category("Appearance"),
Description("Fixes up linefeeds for display replacing CHR(10) with CHR(13)+CHR(10). Useful for data that was transformed through XML."),
DefaultValue(false)]
public bool FixupLinefeeds
{
get { return this.bFixupLinefeeds; }
set { this.bFixupLinefeeds = value; }
}
bool bFixupLinefeeds = false;
public override string Text
{
get
{
return base.Text;
}
set
{
if (this.FixupLinefeeds)
{
const string PLACEHOLDER = "%%%%";
string T = value.Replace("\r\n",PLACEHOLDER);
T = T.Replace("\n",PLACEHOLDER);
T = T.Replace("\r","\r\n");
value = T.Replace(PLACEHOLDER,"\r\n");
}
base.Text = value;
}
}
}
This obviously causes the data to be changed on the fly without the user doing anything, so you need to be careful with this approach. It only fixes up the data one-way – it doesn’t put it back into the original non proper format.
This is a down and dirty hack but it seems to have resolved this issue quickly. I suspect a RegEx expression might do the job more efficiently than the above code too, but my regex skills are minimal. If you figure a more efficient way please leave a comment. So far perf doesn’t seem to be an issue even on a form that has about 10 long edit fields where this stuff applies.