Why doesn't MaxLength work with multiline TextBoxes?

[danthman]

I have a TextBox set up as follows:

<asp:TextBox
ID="SubjectTextBox"
TextMode="MultiLine"
MaxLength="100"
Columns="50"
Rows="2"
Wrap="true"
runat="server" />

The ideas is that users get 100 characters to specify their subject. In
fact, the content of this TextBox will get inserted into a database
field whose data type is VARCHAR(100).

Unfortunately, the MaxLength property gets disabled/ignored when the
TextMode is set to "multiline." This isn't officially a bug, since it's
mentioned in the documentation, but it certainly is a design flaw in my
opnion.

Now I have to set up a validator to make sure the string isn't too
long, and users will have no idea they have typed too much until they
hit Submit and get an error message. I suppose I could say "max of 100
characters" next to the textbox, but this will clutter up the page,
and, assuming users even know what a "character" is, what are they
supposed to do, count?

I don't know if this is a Microsoft thing or just a limitation with
html, but I hope someone fixes it soon.

-Dan

 

[Joerg Jooss]

Hello danthman,

I have a TextBox set up as follows:

<asp:TextBox
ID="SubjectTextBox"
TextMode="MultiLine"
MaxLength="100"
Columns="50"
Rows="2"
Wrap="true"
runat="server" />
The ideas is that users get 100 characters to specify their subject.
In fact, the content of this TextBox will get inserted into a database
field whose data type is VARCHAR(100).

Unfortunately, the MaxLength property gets disabled/ignored when the
TextMode is set to "multiline." This isn't officially a bug, since
it's mentioned in the documentation, but it certainly is a design flaw
in my opnion.

Well, tell that to the HTML spec designers ;-)

All ASP.NET web controls are ultimately rendered as HTML elements. Unfortunately,
a TextArea has no MaxLength property...

Cheers,

 

[Jeff]

The ASP.NET TextBox of one line renders as an HTML <INPUT type="Text"... >
element, whereas a TextBox with multiple lines renders as an HTML <TextArea>
element, which has no MaxLength property per the HTML specification. This
isn't a specification that Microsoft put together. This is what we got from
the lovely standards commmittee.

A couple of workarounds:
http://www.dynamicdrive.com/dynamicindex16/maxlength.htm

http://www.siteexperts.com/ie5/htc/ts08/page1.asp

Another workaround is to use a validator with its problems as you are
already apparently aware.

-Jeff

 

[Peter Rilling]

MS could have, however, emitted the JavaScript necessary to restrict the
number of characters. You can do that, but it requires JavaScript to count
the number of characters with each key stroke.

 

[Nathan Sokalski]

As everyone else mentioned, it is due to the limitations of HTML. However, I
believe the reason for this has something to do with carriage returns, line
breaks, and other whitespace characters used between lines. Different
browsers and operating systems might use different combinations of these
characters to represent a new line, and depending on whether they use a
single character or the combination of Chr(13) and Chr(10) like Microsoft
does, the same text may be a different number of characters. Because I have
read the specs cover to cover, I don't know for sure, but this is my guess.

 

[Aquila Deus]

I have a TextBox set up as follows:

<asp:TextBox
ID="SubjectTextBox"
TextMode="MultiLine"
MaxLength="100"
Columns="50"
Rows="2"
Wrap="true"
runat="server" />

The ideas is that users get 100 characters to specify their subject. In
fact, the content of this TextBox will get inserted into a database
field whose data type is VARCHAR(100).

Unfortunately, the MaxLength property gets disabled/ignored when the
TextMode is set to "multiline." This isn't officially a bug, since it's
mentioned in the documentation, but it certainly is a design flaw in my
opnion.

Now I have to set up a validator to make sure the string isn't too
long, and users will have no idea they have typed too much until they
hit Submit and get an error message. I suppose I could say "max of 100
characters" next to the textbox, but this will clutter up the page,
and, assuming users even know what a "character" is, what are they
supposed to do, count?

You should always setup validators for limitations. The MaxLength you
set with TextBox affects only the UI - users can still send you a
1GB-long text without being cut (they dont have to use a browser).

Maybe ASP.NET should add automatic validators for that in next version?

 

[danthman]

Pardon my naivete, but how do you send text without using the
interface? And, if you did do that, what good would it do to write a
validator that checks what's been typed into the textbox? Also, what
would happen if someone sent something bigger than the max the database
field is set up to hold (e.g., VARCHAR(100))? Wouldn't it just generate
an error and reject the attempt?

Thanks,

-Dan

 

[Peter Rilling]

The UI is simply an easy way to allow the user to input information. The
information sent to the browser is simply a text document that is then
processed. In the simple case, a user might setup a bunch of hidden fields
that are named the same as your input fields and set the values. Then they
can submit that form to your page. There is no difference between a hidden
field and a UI field from the perspective of the server (they are all just
name/value pairs). A more complicated plan might be to craft the post data
(sans a web page) that the server will process, which as I mentioned is
really only a text document.

The point being that the client is very susceptible to spoofing and that no
assumptions should be made in case some bad hacker decides your sites is
worth spoofing.

 

[Aquila Deus]

Pardon my naivete, but how do you send text without using the
interface?

Just HTTP. The browser is the *user*'s tool to connect to your server.
You can't do real validation based on his own tool.

And, if you did do that, what good would it do to write a
validator that checks what's been typed into the textbox?

It should be provided automatically. Since a control in ASP.NET is like
a GUI control, its behavior should also be consistent.

Also, what
would happen if someone sent something bigger than the max the database
field is set up to hold (e.g., VARCHAR(100))? Wouldn't it just generate
an error and reject the attempt?

It could cause buffer overflow or other weird error before your DB
validates it against the field length. Also, with MySQL's MyISAM DB,
it's just truncated without any error thrown.

Database is mainly for storage, and you'd have a lot of trouble if you
want to rely on it for other tasks. Think of a simple example: you have
a table with field "name" and field "password", both are VARCHAR(20),
and some user gives a password of 21 chars. Here the problem comes: DB
rejects the INSERT, but how do you know which field is wrong? The
length checking is not a named constraint, and every DBs report error
in different ways!

 

[danthman]

Thanks, guys.

Okay, so tell me if I have this right...

The validation is done by the server. Users can send whatever they want
to the server by writing their own html files and loading them in their
browsers, but if I write validators to protect against all bad data,
they can't hurt me (well, not easily anyway).

I'm a littler hazier on the database issue though. If I send too much
data to the database, and it causes "buffer overflow or some other
wierd error," would this crash my server? Or would the user's attempt
just simply not work and cause them to see a cryptic error message?

I will definitely do my best to validate against all possible bad data,
but if I miss something, I hope it's at least very difficult to crash
the server. If it were just a matter of someone getting an unhandled
exception or something, I could live with that, especially if they did
something malicious to generate the exception

Anyway, thanks for the warning. I'll work on some stricter validators.

-Dan

 

[Jeff]

Re:
<<... Or would the user's attempt just simply not work and cause them to see
a cryptic error message?>>

How about "none of the above"...
What you can do is write code that checks the length of the incoming value
prior to any attempt to write to the database. When it's too long you can do
whatever you want... disallow the insert/update, return a message to the
user, whatever you want to do, really. The big point here is that you don't
have to worry about what will happen. Just validate everything explicitly
before attempting to save to the database. When the validation fails, take
whatever corrective action makes sense for your scenario.

-HTH

 

[elizas]

Restrict to insert carriage return into Textbox control

Its check each character’s ASCII value entered into the textbox, so when the enter key is pressed its also check the ASCII value and then it avoid to insert the carriage return value to the textbox. So we can avoid to insert Carriage Return into the textbox having “ Multiline” TextMode property or in TextArea control.

<asp:TextBox ID="txtComments" Height="150" Columns="200" TextMode="multiline" MaxLength="4000" runat="server" onkeydown = "return (event.keyCode!=13);" />

Note: ASCII value for Enter Key is 13.