This covers one problem we've got about newlines:
Let's summarize how newlines are handled in SWF and in different
browsers ("input" -> "output"):
SWF-behaviour:
\n -> \r
\r -> \r
\r\n -> \r\r (!this gives two newlines!)
FF-behaviour:
\n -> \n
\r -> \n
\r\n -> \n
IE-behaviour
\n -> \r\n
\r -> \r\n
\r\n -> \r\n
So, IE does always convert newlines to "\r\n", which gives a length of 2
for every newline. And to get the same length as in SWF/FF, I've simply
used a RegExp. Re-converting is unnecessary in this case, because this
is done automatically by IE.
For the same reason, LzInputTextSprite#getText() has been changed.
But I've just found two other bugs related to multiline
inputtext-fields. I'll resend a new changeset.
On 11/4/2007 4:09 AM, Philip Romanik wrote:
Approved, but don't you need to make one change? For IE, you convert
\r\n to \n, but you don't convert it back after clipping the string.
I tried IE6 / IE7 / FF2 / Opera9 / Safari3.0.3PC
Change 20071103-bargull-0 by [EMAIL PROTECTED] on 2007-11-03
18:09:41 in /home/Admin/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: Add maxlength-support for multiline inputtexts (DHTML)
New Features:
Bugs Fixed:
LPP-4747 - "Edittext maxlength does not work"
Technical Reviewer: max
QA Reviewer: promanik
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
The HTML-<textarea> object does not support maxlength natively, so we
need to implement a js-solution in DHTML.
I've used the "onkeyup"-event to check the current text-length and if
the length exceeds its limit and I simply re-assigning the value
property of the <textarea> object. This approach does not give the
best visual experience, because the maxlength-test does happen after
the new input is already visible for the user. Alternatives to
"onkeyup" are:
"onkeydown" and "onkeypress".
contra "onkeydown": we cannot determine which character the user
enters, because we just have access to the "keyCode", which
represents the pressed key on the keyboard (think about different
keyboard-layouts, OS,
etc.)
contra "onkeypress": (sometimes,) we can determine which character
the user enters. "sometimes" means, it's browsers-dependent. For
example, IE and FF do give us this char-information (through
"keyCode" resp.
"charCode"), but no chance in Opera (I did test not Safari). Opera's
handling is somehow "interesting": if you press a "alphanumeric"-key,
you get the char-code through "keyCode", but if you press a
"function"-key, you get the key-code through "keyCode" ("charCode" is
not supported in Opera). So it's almost the same problem as for
"onkeydown", because we cannot easily determine which character was
entered by the user.
I am open for any suggestions for this changeset (i.e.: implement
"onkeypress"-handling for IE/FF/?, and "onkeyup" for Opera/?). It'd
be good to know how Safari handles this issue, because Safari is an
A-list browser whereas Opera is just B-list.
Tests:
Files:
M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
M WEB-INF/lps/lfc/kernel/dhtml/LzInputTextSprite.js
Changeset:
http://svn.openlaszlo.org/openlaszlo/patches/20071103-bargull-0.tar
