Skip to main content



      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 18:33 Go to next message
Eclipse UserFriend
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 09:28 Go to previous messageGo to next message
Eclipse UserFriend
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 12:13 Go to previous messageGo to next message
Eclipse UserFriend
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] Fri, 08 May 2009 22:38 Go to previous messageGo to next message
Eclipse UserFriend
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 18:15 Go to previous messageGo to next message
Eclipse UserFriend
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 01:31 Go to previous messageGo to next message
Eclipse UserFriend
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 11:32 Go to previous messageGo to next message
Eclipse UserFriend
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 11:42 Go to previous messageGo to next message
Eclipse UserFriend
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 13:10 Go to previous message
Eclipse UserFriend
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: Fri Oct 31 04:16:00 EDT 2025

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

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

Back to the top