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
|
