[Laszlo-dev] For Review: Change 20071103-bargull-0 Summary: Add maxlength-support for multiline inputtexts (DHTML)

[André Bargull]

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 bargull at dell--p4--2-53 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