You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2009/10/29 19:10:11 UTC
Re: svn commit: r831049
Please note that, as a result of this change, TextInput is temporarily
not completely functional. If you are developing an application that
relies on a working TextInput component, you may want to avoid syncing
with SVN until the remaining issues are worked out (hopefully fairly
soon).
G
Re: svn commit: r831049
Posted by Sandro Martini <sa...@gmail.com>.
> This will not be a trivial change. Can you explain in more detail why the current implementation is not sufficient?
Yes.
> I understand that the bar code scanner appends a CR/LF to the text, but this keystroke will simply be ignored by TextInput. Even if TextInput accepted the control characters, it wouldn't display them - so I am wondering why you even need this functionality.
Mhhh so probably current features could be enough for the display part
... I don't have to display control chars (never), and by default they
have to be filtered out, probably as currently, Ok.
But in a my application (done in dot Net, sigh) I had to test in the
input string for CR LF chars to identify if the barcode read was
complete (because barcode readers only writes the code in the input
box, char by char).
In my first version the application had a thread that any second tried
to read the input text and verify if changed with the previous
(without using control chars for marking the end of code) but this I
had some problems with timings (the app was running on a Windows CE
device, with the compact version of the latest dot Net) etc ...
So in the second version I set the dot Net input text to not filter
control chars, and simply use an event listener of onChange of
contents with inside a simple test of CR LF to ensure the barcode was
read successfully.
All of this because my customers used many different barcodes so I
couldn't rely also on a (one or more) common pattern (like a regexp)
to identify codes.
Tell me if it's not enough clear.
I agree that this could be a corner case for us ... but if dot Net
have this feature probably could be useful in many other situations
:-) .
Have you got some suggestion for the description the feature the JIRA ticket ?
Then probably this feature could be applied also to TextArea ... but
maybe later.
Thanks for the help,
Sandro
Re: svn commit: r831049
Posted by Greg Brown <gk...@mac.com>.
This will not be a trivial change. Can you explain in more detail why the current implementation is not sufficient? I understand that the bar code scanner appends a CR/LF to the text, but this keystroke will simply be ignored by TextInput. Even if TextInput accepted the control characters, it wouldn't display them - so I am wondering why you even need this functionality.
On Friday, October 30, 2009, at 09:34AM, "Sandro Martini" <sa...@gmail.com> wrote:
>> It is possible. I would consider it a very low priority item, but feel free to file a JIRA ticket if you like. I would suggest assigning it to version 2.0 or later.
>Ok.
>But for a my application I'll need it (so this is one of my
>priorities), so I can start to look at it (when you'll have finished
>the work on TextInput), Ok ?
>
>So I'll add in JIRA, but for 1.5 (and if possible I'll release before).
>
>Thanks,
>Sandro
>
>
Re: svn commit: r831049
Posted by Sandro Martini <sa...@gmail.com>.
> It is possible. I would consider it a very low priority item, but feel free to file a JIRA ticket if you like. I would suggest assigning it to version 2.0 or later.
Ok.
But for a my application I'll need it (so this is one of my
priorities), so I can start to look at it (when you'll have finished
the work on TextInput), Ok ?
So I'll add in JIRA, but for 1.5 (and if possible I'll release before).
Thanks,
Sandro
Re: svn commit: r831049
Posted by Greg Brown <gk...@mac.com>.
It is possible. I would consider it a very low priority item, but feel free to file a JIRA ticket if you like. I would suggest assigning it to version 2.0 or later.
On Friday, October 30, 2009, at 06:15AM, "Sandro Martini" <sa...@gmail.com> wrote:
>Hi Greg,
>with the TextInput component, is it possible to handle also control
>chars (like CR + LF) and maybe a style flag to keep them in the text
>(but without displaying them) or by default filtering them out ?
>
>In dot Net the related component has this feature, and in some cases
>could be very useful.
>For example I used this feature in an application that reads data from
>BarCode Readers (where the end of the barcode was a CR LF).
>
>What do you think ?
>
>Bye
>
>
Re: svn commit: r831049
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
with the TextInput component, is it possible to handle also control
chars (like CR + LF) and maybe a style flag to keep them in the text
(but without displaying them) or by default filtering them out ?
In dot Net the related component has this feature, and in some cases
could be very useful.
For example I used this feature in an application that reads data from
BarCode Readers (where the end of the barcode was a CR LF).
What do you think ?
Bye
Re: svn commit: r831049
Posted by Greg Brown <gk...@mac.com>.
OK, TextInput is still not completely functional but it is now usable.
Features that are still missing include auto-scrolling and maintaining
caret visibility when the text is too long to fit into the available
space. These features will be restored as soon as possible.
On Oct 29, 2009, at 2:10 PM, Greg Brown wrote:
> Please note that, as a result of this change, TextInput is
> temporarily not completely functional. If you are developing an
> application that relies on a working TextInput component, you may
> want to avoid syncing with SVN until the remaining issues are worked
> out (hopefully fairly soon).
> G
>
Re: svn commit: r831049
Posted by Greg Brown <gk...@mac.com>.
OK, TextInput is still not completely functional but it is now usable.
Features that are still missing include auto-scrolling and maintaining
caret visibility when the text is too long to fit into the available
space. These features will be restored as soon as possible.
On Oct 29, 2009, at 2:10 PM, Greg Brown wrote:
> Please note that, as a result of this change, TextInput is
> temporarily not completely functional. If you are developing an
> application that relies on a working TextInput component, you may
> want to avoid syncing with SVN until the remaining issues are worked
> out (hopefully fairly soon).
> G
>