Dont fell bad dude! This way we can improve faster everybody!
thank you very much for the "idea" of how treat this problem. Sure i
will have to make modifications on the code here.
if i could help ya on anyway, just ask! ;)
[]'s
Luís
Jason Stafford escreveu:
> I feel bad that I mentioned that I had a solution to this at all,
> since I don't have an open source one, but I don't have the time right
> now to explain in English how to write the code. Here is the code we
> use (which is copyright 2006 Inspiration Software, All rights
> reserved). >From studying this you should be able to create your own
> solution. Note that in our case we are allowing new line and tab, but
> disallowing all other low ascii. If you want to strip out new lines
> as well, just remove the test for lCharCode == 10:
>
>// Copyright 2006 Inspiration Software, All rights reserved.
><script>
><![CDATA[
> cleanText = function( inText )
>
> {
>
> var lLength = inText.length;
>
> var lCleanText = "";
>
> var i;
>
> var lChar;
>
> var lCharCode;
>
> for ( i = 0; i < lLength; i++ )
>
> {
>
> lChar = inText.charAt( i );
>
> lCharCode = lChar.charCodeAt(0);
>
> if ( lCharCode > 31 || lCharCode == 9 || lCharCode == 10 )
>
> {
>
> lCleanText += lChar;
>
> }
>
> }
>
>
>
> return lCleanText;
>
> }
>
>]]>
></script>
>
>
> <edittext>
>
> <handler name='ontext' reference='this.field'>
>
> <![CDATA[
>
> var lText = this.getText();
>
> var lCleanText = cleanText(lText);
>
> var lDiff = lText.length - lCleanText.length;
>
>
>
> if (lDiff != 0)
>
> {
>
> var lSaveSelStart =
> this.field.getSelectionPosition();
>
> var lSaveSelSize = this.field.getSelectionSize();
>
>
>
> this.setText(lCleanText);
>
>
>
> if (lSaveSelStart >= 0 && lSaveSelSize >= 0 )
>
>
> this.field.setSelection(lSaveSelStart-lDiff,lSaveSelStart+lSaveSelSize-lDiff);
>
> }
>
> ]]>
>
> </handler>
>
> </edittext>
>
>
> Of course if you're going to be putting this into multiple spots,
> you'd want to make the body of this handler a method, so you don't end
> up with duplicated code all over the place.
> -Jason
>
>
>
> Luis Eduardo wrote:
>
>>from the link given:
>>
>>
>> ["String key mapping
>>
>>To map string (function) keys, use the *mapstr* (see the *mapkey*(M)
>><http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?mapkey+M> manual
>>page) utility. *mapstr* modifies the string mapping table where function
>>keys are defined. "]
>>
>>aaa dude... would be nice if we could only do such a thing on a
>>javascript (or something that comes within laszlo) and, by some kind of
>>magic, the O.S started to mapping keys on the way we want to our software.
>>
>>anyway, you tell that in your application you filter the keys on ontext
>>handler and can deal with this ctrl+j problem...
>>can you give more details about this?
>>
>>pleeeease? :)
>>
>>
>> Luís Eduardo.
>>
>>
>>
>>
>>Jason Stafford escreveu:
>>
>>
>>
>>>To answer the question, "But, why Ctrl-J?" take a look at this helpful
>>>page:
>>>
>>>http://en.wikipedia.org/wiki/Control_character
>>>
>>>Since J is 0x4A in ASCII, and since CTRL subtracts decimal 64 from the
>>>character it combines with, then CTRL+J must be 0x0A, or new line.
>>>
>>>Why these ancient keyboard shortcuts for generating low ASCII control
>>>characters are still supported in this modern day is another question
>>>entirely, but I'm sure there was some important reason for this
>>>"backwards compatibility" that has carried through all these years.
>>>
>>>In our OpenLaszlo application, we've found many other CTRL characters
>>>to causes all kinds of headaches, so we just filter them out in the
>>>ontext handler, or the onblur handler, depending on the circumstance.
>>>
>>>The following page contains a table listing all the values generated
>>>by the keys with the various modifiers down, if you're really curious:
>>>http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?keyboard+HW
>>>
>>>-Jason
>>>
>>>[EMAIL PROTECTED] wrote:
>>>
>>>
>>>
>>>>Ben,
>>>>
>>>>I tested with servlet based LPS version 3.1.1 and 3.3.3.
>>>>Internet Explorer 6.0.2900
>>>>
>>>>per your suggestion, I logged a bug for this:
>>>>http://www.openlaszlo.org/jira/browse/LPP-2622
>>>>
>>>>Thank you.
>>>>
>>>>Sanjaya
>>>>
>>>>On Wed, Sep 6, 2006 at 8:44 PM, Benjamin Shine wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I hadn't heard of this one before -- please file a bug. But, why
>>>>>Ctrl-J?
>>>>>Also, which version of OpenLaszlo?
>>>>>
>>>>>On Sep 6, 2006, at 7:04 PM, [EMAIL PROTECTED] wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>I experience unwanted linefeed character inside edittext or inputtext
>>>>>>object. I capture the screenshot for the behavior.
>>>>>>
>>>>>>To reproduce the behavior, run the attached simple testcase in
>>>>>>Internet
>>>>>>Explorer, put focus in the edittext object and press CTRL+J once,
>>>>>>type
>>>>>>'1', CTRL+J and type '2' and so on, you will see that a new line is
>>>>>>inserted after the CTRL+J.
>>>>>>
>>>>>>the internal '.field' inputtext is resized and growed outside the
>>>>>>border.
>>>>>>
>>>>>>a new line will continously be inserted causing the field to grow as
>>>>>>you
>>>>>>hit CTRL+J ... in the GUI it maxed out to 3 lines, but the entered
>>>>>>text
>>>>>>can still grow.
>>>>>>
>>>>>>repeating similar testcase for the bottom inputtext object, doesn't
>>>>>>resize
>>>>>>the inputtext object, but the new line still get inserted.
>>>>>>
>>>>>>I searched for info in documentation, forum and JIRA .. no luck. I
>>>>>>may be
>>>>>>miss it.
>>>>>>
>>>>>>I did a bit research and found that this is a known issue for flash
>>>>>>player
>>>>>>(http://tinyurl.com/k7wze)
>>>>>>
>>>>>>I wonder if anyone know a workaround for this.
>>>>>>
>>>>>>Thanks
>>>>>>
>>>>>>Sanjaya
>>>>>><test-ctrl-j.lzx>
>>>>>><ctrl-j in IE.gif>
>>>>>>
>>>>>>_______________________________________________
>>>>>>Laszlo-user mailing list
>>>>>>[email protected]
>>>>>>http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>_______________________________________________
>>>>Laszlo-user mailing list
>>>>[email protected]
>>>>http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>>>>
>>>>
>>>>
>>>>
>>>--
>>>Jason Stafford
>>>Principal Developer
>>>Inspiration Software, Inc.
>>>The leader in visual thinking & learning
>>>
>>>InspireData(tm), the newest innovative thinking and learning tool from
>>>Inspiration Software(r), extends the proven power of visual learning to
>>>data analysis. Learn more at www.inspiration.com.
>>>
>>>503-297-3004 Extension 119
>>>503-297-4676 (Fax)
>>>9400 SW Beaverton-Hillsdale Highway
>>>Suite 300
>>>Beaverton, OR 97005-3300
>>>
>>>
>>>------------------------------------------------------------------------
>>>
>>>
>>>_______________________________________________
>>>Laszlo-user mailing list
>>>[email protected]
>>>http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>>>
>>>
>>>
>>>
>>
>>
>>_______________________________________________
>>Laszlo-user mailing list
>>[email protected]
>>http://www.openlaszlo.org/mailman/listinfo/laszlo-user
>>
>>
>
>--
>Jason Stafford
>Principal Developer
>Inspiration Software, Inc.
>The leader in visual thinking & learning
>
>InspireData(tm), the newest innovative thinking and learning tool from
>Inspiration Software(r), extends the proven power of visual learning to
>data analysis. Learn more at www.inspiration.com.
>
>503-297-3004 Extension 119
>503-297-4676 (Fax)
>9400 SW Beaverton-Hillsdale Highway
>Suite 300
>Beaverton, OR 97005-3300
>
>
_______________________________________________
Laszlo-user mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-user
