Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Remote Application Platform (RAP) » setTextLimit for Text Doesn't Work?
setTextLimit for Text Doesn't Work? [message #131929] Thu, 07 May 2009 22:33 Go to next message
Howard is currently offline HowardFriend
Messages: 29
Registered: July 2009
Junior Member
I've filed a bug 275391

========== Pasted from the bug ===============

Code to reproduce:
Text text = new Text(parent, SWT.MULTI);
text.setTextLimit(128);

Yet I can enter as much data as I want. If I remove SWT.MULTI, then
setTextLimit() works perfectly.

This is a severe issue for our software due to needing to limit the amount
of data users can enter to correspond to database limits. It is a pain to
hunt down all the places that this is breaking in our fairly complex
application converted from SWT.

===============================================

If this can be fixed by M7 I would be oh so grateful. We're just getting
ready to ship our software the week after and I would love to update to M7
and ship with it since it contains many bug fixes. Pleeeeeeaaaaaase~~~~ :D

Cheers,
Howard
Re: setTextLimit for Text Doesn't Work? [message #131981 is a reply to message #131929] Fri, 08 May 2009 13:28 Go to previous messageGo to next message
Rüdiger Herrmann is currently offline Rüdiger HerrmannFriend
Messages: 581
Registered: July 2009
Senior Member
Howard,

this is a known issue in qooxdoo. Please see the comment on the bug.

Cheers,
Rüdiger

Howard wrote:
> I've filed a bug 275391
>
> ========== Pasted from the bug ===============
>
> Code to reproduce:
> Text text = new Text(parent, SWT.MULTI);
> text.setTextLimit(128);
>
> Yet I can enter as much data as I want. If I remove SWT.MULTI, then
> setTextLimit() works perfectly.
>
> This is a severe issue for our software due to needing to limit the
> amount of data users can enter to correspond to database limits. It is
> a pain to hunt down all the places that this is breaking in our fairly
> complex application converted from SWT.
>
> ===============================================
>
> If this can be fixed by M7 I would be oh so grateful. We're just
> getting ready to ship our software the week after and I would love to
> update to M7 and ship with it since it contains many bug fixes.
> Pleeeeeeaaaaaase~~~~ :D
>
> Cheers,
> Howard
>
Paging Ivan! [message #132036 is a reply to message #131981] Fri, 08 May 2009 16:13 Go to previous messageGo to next message
Howard is currently offline HowardFriend
Messages: 29
Registered: July 2009
Junior Member
Thanks for the quick responses.

Is there a way for me to patch in the fix in case the Qooxdoo team doesn't
respond by Monday morning?


Also...is M7 on track to come out on Monday? Any idea what time frame?

Howard
Re: Paging Ivan! [message #132074 is a reply to message #132036] Sat, 09 May 2009 02:38 Go to previous messageGo to next message
Ivan Furnadjiev is currently offline Ivan FurnadjievFriend
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Howard,

M7 is already on the way. Patching Qooxdoo about this bug is not an easy
task - this functionality is missing from the qooxdoo TextArea component
(HTML textarea has no such attribute maxLength).
As a workaround you can use a verify listener to check the typed
content length and not to allow the characters to exceed the max limit.

Best,
Ivan

Howard wrote:
> Thanks for the quick responses.
>
> Is there a way for me to patch in the fix in case the Qooxdoo team
> doesn't respond by Monday morning?
>
>
> Also...is M7 on track to come out on Monday? Any idea what time frame?
>
> Howard
>
Re: Paging Ivan! [message #132279 is a reply to message #132074] Mon, 11 May 2009 22:15 Go to previous messageGo to next message
Howard is currently offline HowardFriend
Messages: 29
Registered: July 2009
Junior Member
Thanks Ivan.

I tried to implement the verify listener, and noticed that RAP VerifyEvent
extends TypedEvent instead of KeyEvent like SWT. This means no access to
character field, so I can't test for BackSpace character. This is
annoying because if I'm AT the limit, and try to backspace, I'll trigger
this check:

limit <= textField.getCharCount()

which means either the popping a warning, or setting e.doit=false.
Neither of which is pretty without the backspace check to allow deletion.
Any suggestions?

Howard


Ivan Furnadjiev wrote:

> Howard,

> M7 is already on the way. Patching Qooxdoo about this bug is not an easy
> task - this functionality is missing from the qooxdoo TextArea component
> (HTML textarea has no such attribute maxLength).
> As a workaround you can use a verify listener to check the typed
> content length and not to allow the characters to exceed the max limit.

> Best,
> Ivan

> Howard wrote:
>> Thanks for the quick responses.
>>
>> Is there a way for me to patch in the fix in case the Qooxdoo team
>> doesn't respond by Monday morning?
>>
>>
>> Also...is M7 on track to come out on Monday? Any idea what time frame?
>>
>> Howard
>>
Re: Paging Ivan! [message #132292 is a reply to message #132279] Tue, 12 May 2009 05:31 Go to previous messageGo to next message
Ivan Furnadjiev is currently offline Ivan FurnadjievFriend
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Hi Howard,

maybe you don't need to test the BackSpace character at all. In the
verifyText if the text length is above the limit, substring it to the
textLimit and set the event.text to the substringed value.

Best,
Ivan

Howard wrote:
> Thanks Ivan.
>
> I tried to implement the verify listener, and noticed that RAP
> VerifyEvent extends TypedEvent instead of KeyEvent like SWT. This
> means no access to character field, so I can't test for BackSpace
> character. This is annoying because if I'm AT the limit, and try to
> backspace, I'll trigger this check:
>
> limit <= textField.getCharCount()
>
> which means either the popping a warning, or setting e.doit=false.
> Neither of which is pretty without the backspace check to allow
> deletion. Any suggestions?
>
> Howard
>
>
> Ivan Furnadjiev wrote:
>
>> Howard,
>
>> M7 is already on the way. Patching Qooxdoo about this bug is not an
>> easy task - this functionality is missing from the qooxdoo TextArea
>> component (HTML textarea has no such attribute maxLength).
>> As a workaround you can use a verify listener to check the typed
>> content length and not to allow the characters to exceed the max limit.
>
>> Best,
>> Ivan
>
>> Howard wrote:
>>> Thanks for the quick responses.
>>>
>>> Is there a way for me to patch in the fix in case the Qooxdoo team
>>> doesn't respond by Monday morning?
>>>
>>>
>>> Also...is M7 on track to come out on Monday? Any idea what time frame?
>>>
>>> Howard
>>>
>
>
Still no joy...help?! [message #132413 is a reply to message #132292] Tue, 12 May 2009 15:32 Go to previous messageGo to next message
Howard is currently offline HowardFriend
Messages: 29
Registered: July 2009
Junior Member
That's an interesting idea, but unless I'm doing something wrong, the
solution still doesn't work that well in RAP. Works great in SWT of
course.

if (limit < textField.getCharCount()) {
e.text = textField.getText().substring(0, limit);
}

Seems like RAP doesn't get the e.start and e.end fields cleanly, and/or
setting e.text. I'm able to exceed the limit if I type fast. And I just
remembered that RAP doesn't check every character but in bunches, which
then makes sense that any of these solutions won't work all that well.

I guess unless there are any more solutions, I would need to TRY to help
the user out by attempting to limit/warn the user, and then manually
truncate incoming data.

Howard
Re: Still no joy...help?! [message #132426 is a reply to message #132413] Tue, 12 May 2009 15:42 Go to previous messageGo to next message
Ivan Furnadjiev is currently offline Ivan FurnadjievFriend
Messages: 2426
Registered: July 2009
Location: Sofia, Bulgaria
Senior Member
Howard,

get the text from the event object itself and not from the textField.
Something like that:

String text = event.text;
if (limit < text.length) {
e.text = text.substring(0, limit);
}

Please note that the RAP verify event text field differ from the SWT and
contains the complete text (not only the modified region). See this bug
for more details:
244008: VerifyEvent field values differ from SWT
https://bugs.eclipse.org/bugs/show_bug.cgi?id=244008

Best,
Ivan

Howard wrote:
> That's an interesting idea, but unless I'm doing something wrong, the
> solution still doesn't work that well in RAP. Works great in SWT of
> course.
>
> if (limit < textField.getCharCount()) {
> e.text = textField.getText().substring(0, limit);
> }
>
> Seems like RAP doesn't get the e.start and e.end fields cleanly,
> and/or setting e.text. I'm able to exceed the limit if I type fast.
> And I just remembered that RAP doesn't check every character but in
> bunches, which then makes sense that any of these solutions won't work
> all that well.
>
> I guess unless there are any more solutions, I would need to TRY to
> help the user out by attempting to limit/warn the user, and then
> manually truncate incoming data.
>
> Howard
>
Re: Still no joy...help?! [message #132467 is a reply to message #132426] Tue, 12 May 2009 17:10 Go to previous message
Howard is currently offline HowardFriend
Messages: 29
Registered: July 2009
Junior Member
Ah, MUCH better! Thought I tried that too but probably didn't get it just
right. I actually was about to post that doing the check in
ModifyListener works pretty well too since that's after the fact.

Thanks much!
Howard
Previous Topic:10 new Google Visualization widgets for RAP
Next Topic:Order of resources / external JS libraries
Goto Forum:
  


Current Time: Thu Apr 25 10:49:24 GMT 2024

Powered by FUDForum. Page generated in 0.03825 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top