You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Sandro Martini <sa...@gmail.com> on 2009/06/15 12:08:57 UTC
ReadOnly elements and i18n Validators
Hi to all,
I'm doing some run tests on some WTK Test Applications, but I've seen
some things, maybe someone could explain better to me ...
- in ListViewTest I'm not able to set the ListView in a Read-Only mode
(for example I pre-select some elements by code and them i don't want
the user to modify this selection, but i could change this by code
later, for whatever reason), but only in a disabled status.
- in ListViewTest I've seen the setItemChecked method, and related
method setItemChecked .
But if i comment the setItemChecked call, i got an IllegalStateException, ok.
To select elements in this case now I have to use setSelectedIndex ,
or more the addSelectedIndex ... but aren't all these methods doing
the same thing: selecting elements in the list ?
Maybe could be simpler to have only one method to select elements,
depending what to do on the SelectMode and Checked flag ?
- in TextInputValidatorTest, as in the first note here I've seen it's
not possible to put a Text Input in Read-Only mode ... and maybe all
other Pivot elements, right ?
- in TextInputValidatorTest, in the textinputFloatRange I've seen that
giving inputs in the current Locale all works good, but I haven't find
a way to change the Locale, or to set a different format to validators
... how can i do this ?
Maybe the simplest thing could be to set a different Locale and let
validators using it, in this case all the application would use only a
Locale, but i think this is a common case (only a few times i had to
manage more locales in the same application, showing more at the same
time to the same user ... ).
I have to run my applications in a multi-locale environment (but any
user with its default or chosen locale) ... thanks.
Thanks,
Sandro
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
Sounds like a good plan to me.
On Jun 17, 2009, at 9:10 AM, Noel Grandin wrote:
> Hi
>
> Hmm, good points, I had not considered this use-case.
>
> I think the best solution for this is:
> (1) make DecimalValidator not abstract - the reason it is currently
> abstract is a historical hold-over
> (2) make the DecimalValidator constructors public
> (3) modify the various *Validator classes to have extra constructors
> that take a Locale parameter.
>
> Please log a JIRA ticket for this.
>
> If there are no objections, I can make the changes tomorrow morning.
>
> Regards, Noel.
>
> Greg Brown wrote:
>>> - in TextInputValidatorTest, in the textinputFloatRange I've seen
>>> that
>>> giving inputs in the current Locale all works good, but I haven't
>>> find
>>> a way to change the Locale, or to set a different format to
>>> validators
>>> ... how can i do this ?
>>
>> Noel may be able to comment on this one.
>>
>>
>
>
Re: ReadOnly elements and i18n Validators
Posted by Sandro Martini <sa...@gmail.com>.
Hi Noel,
thanks for the feedback, I'll open a ticket for an improvement for the
1.3 release.
But i haven't found your user in JIRA, so by default i have assigned
Greg :-) ...
Bye,
Sandro
Re: ReadOnly elements and i18n Validators
Posted by Noel Grandin <no...@gmail.com>.
Hi
Hmm, good points, I had not considered this use-case.
I think the best solution for this is:
(1) make DecimalValidator not abstract - the reason it is currently
abstract is a historical hold-over
(2) make the DecimalValidator constructors public
(3) modify the various *Validator classes to have extra constructors
that take a Locale parameter.
Please log a JIRA ticket for this.
If there are no objections, I can make the changes tomorrow morning.
Regards, Noel.
Greg Brown wrote:
>> - in TextInputValidatorTest, in the textinputFloatRange I've seen that
>> giving inputs in the current Locale all works good, but I haven't find
>> a way to change the Locale, or to set a different format to validators
>> ... how can i do this ?
>
> Noel may be able to comment on this one.
>
>
Re: ReadOnly elements and i18n Validators
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
> It is already available for ListView: listView.setSelectMode(ListView.SelectMode.NONE)
Ok, but with this I'm not able to do what i want, because in this case
all previous selection become empty. And, in case of List with Popup
(like Buttons List) having it disabled, I couldn't open the popup to
see elements inside.
For example, take a look at this for the ListViewTest:
// listView.setCheckmarksEnabled(true);
// listView.setItemChecked(4, true);
// listView.setItemChecked(6, true);
// TODO: new code for test
listView.setSelectMode(SelectMode.MULTI);
listView.addSelectedIndex(1);
listView.addSelectedIndex(2);
listView.addSelectedIndex(3);
// TODO: ask for a Read-Only mode ...
// listView.setEnabled(false); // disable list
listView.setSelectMode(SelectMode.NONE); // this clean
selected elements
// listView.setEditable(false); // new, put list in read-only
My use case here is that something in the application select/update
selected elements, and the user doesn't have to change these values,
but only see them (and in the case of popup i can't see them if the
list is disabled).
Tell me if I'm not be clear.
>>So, if will be implemented also for the Text Area ?
> It is already available in TextArea: textArea.setEditable(false)
Ok, sorry for the question ...
Bye
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
>Ok, but if it would be available, also on Lists could be very useful,
>but if you think it's not the case, for me is ok, don't worry.
It is already available for ListView: listView.setSelectMode(ListView.SelectMode.NONE)
>So, if will be implemented also for the Text Area ?
It is already available in TextArea: textArea.setEditable(false)
Re: ReadOnly elements and i18n Validators
Posted by Sandro Martini <sa...@gmail.com>.
Ok, but if it would be available, also on Lists could be very useful,
but if you think it's not the case, for me is ok, don't worry.
So, if will be implemented also for the Text Area ?
And the (optional) read-only/editable style in Skin ?
I have to open a ticket in JIRA ?
One last thing, for Noel (or others, who knows well Pivot Validators),
as reported at the start of this mail thread (some details still are
in the first mail here):
will it be possible to change the Locale used for Validators, when the
application is running, then refresh something to have the new
behavior ?
For multi-language applications this could be useful.
Thanks to all,
Sandro
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
It just doesn't make sense to support a read-only mode for certain components (buttons, spinners, sliders, etc.). However, adding a read-only flag to Calendar would be OK.
On Tuesday, June 16, 2009, at 05:42AM, "Sandro Martini" <sa...@gmail.com> wrote:
>Hi to all,
>et voilà some ideas for the Read-Only mode (or maybe at the opposite,
>a !editable mode ...):
>
>- i imagine elements in read-only fully working and active, they only
>doesn't respond to user for modifying their values, but they respond
>to mouse/keystroke events, and fully updates the graphics (and by code
>i can modify their values).
> Disabled elements instead doesn't respond to user events nor to
>graphics update events until they are enabled, I'm not sure if by
>code i can modify their values (but i think yes), so new values should
>not appear until next refresh (when enabled) and I don't know if in
>this case listener events shouldn't be fired, for consistency.
>
>For example, a read-only Date Picker should expand at mouse click, but
>doesn't change its value.
>
>I hope this is not too different from the current working mode of
>Pivot components ...
>
>
>- i like the Text Input in read-only mode, but if Text Area can have
>it (and if we can constrain text area to a single line, and to work
>like a text input) for me is enough ...
> The plus in this case is to have a control like others in the same
>form (usually forms have many text inputs), visually similar, but for
>many reason in some moments not editable ... then when it will be
>editable i haven't to change a label to text input (or other strange
>tricks), i could only change its read-only status.
>
>- other elements that could have the read-only state are (buttons no, ok):
> Lists (at the moment all lists haven't this) all types including
>list buttons,
> DatePicker (or Calendar Buttons) and Calendars (if not in their
>spinners, at least in the date sheet),
> and other minor cases like Spinners and Sliders, and Splitters ?,
> why not also Checkboxes and maybe Radio Buttons (we should see if
>others GUI toolkit have this feature, i don't remember) ? ... but i
>agree, we can live without this.
>
>Oh, a TimePicker component could be useful, at the moment is missing
>(we can do it with spinners, ok), but a custom version could help. For
>the 1.4 ?
>
>- i agree with you that many components are already read-only
>components (from the user point of view), like Grid, Tree, etc ... i
>have to look better at the Demo "Table Row Editor" on how to edit a
>table row.
>
>- an interesting feature could be also to have a Style for read-only
>elements (or an optional style for any read-only type of elements),
>for example in Substance by default there is an optional lock icon
>near the read-only element.
>
>
>I hope to be clear, if not tell me, but in any case, what do you think ?
>
>
>
>Ah, sorry, one last thing:
>in the Kitchen Sink Demo from the site (
>http://cwiki.apache.org/PIVOT/kitchen-sink-demo.html ), i got a
>Javascript error (Win XP, IE6):
>Line: 35 , Char: 278 , Error: Expected ')'
>and today Firefox hangs on this page ...
>
>
>Bye,
>Sandro
>
>
Re: ReadOnly elements and i18n Validators
Posted by Sandro Martini <sa...@gmail.com>.
Hi to all,
et voilà some ideas for the Read-Only mode (or maybe at the opposite,
a !editable mode ...):
- i imagine elements in read-only fully working and active, they only
doesn't respond to user for modifying their values, but they respond
to mouse/keystroke events, and fully updates the graphics (and by code
i can modify their values).
Disabled elements instead doesn't respond to user events nor to
graphics update events until they are enabled, I'm not sure if by
code i can modify their values (but i think yes), so new values should
not appear until next refresh (when enabled) and I don't know if in
this case listener events shouldn't be fired, for consistency.
For example, a read-only Date Picker should expand at mouse click, but
doesn't change its value.
I hope this is not too different from the current working mode of
Pivot components ...
- i like the Text Input in read-only mode, but if Text Area can have
it (and if we can constrain text area to a single line, and to work
like a text input) for me is enough ...
The plus in this case is to have a control like others in the same
form (usually forms have many text inputs), visually similar, but for
many reason in some moments not editable ... then when it will be
editable i haven't to change a label to text input (or other strange
tricks), i could only change its read-only status.
- other elements that could have the read-only state are (buttons no, ok):
Lists (at the moment all lists haven't this) all types including
list buttons,
DatePicker (or Calendar Buttons) and Calendars (if not in their
spinners, at least in the date sheet),
and other minor cases like Spinners and Sliders, and Splitters ?,
why not also Checkboxes and maybe Radio Buttons (we should see if
others GUI toolkit have this feature, i don't remember) ? ... but i
agree, we can live without this.
Oh, a TimePicker component could be useful, at the moment is missing
(we can do it with spinners, ok), but a custom version could help. For
the 1.4 ?
- i agree with you that many components are already read-only
components (from the user point of view), like Grid, Tree, etc ... i
have to look better at the Demo "Table Row Editor" on how to edit a
table row.
- an interesting feature could be also to have a Style for read-only
elements (or an optional style for any read-only type of elements),
for example in Substance by default there is an optional lock icon
near the read-only element.
I hope to be clear, if not tell me, but in any case, what do you think ?
Ah, sorry, one last thing:
in the Kitchen Sink Demo from the site (
http://cwiki.apache.org/PIVOT/kitchen-sink-demo.html ), i got a
Javascript error (Win XP, IE6):
Line: 35 , Char: 278 , Error: Expected ')'
and today Firefox hangs on this page ...
Bye,
Sandro
Re: ReadOnly elements and i18n Validators
Posted by Todd Volkert <tv...@gmail.com>.
Huh - looks like an artifact of the ScrollPaneSkin optimization. The known
cases where the optimization fails are thought to be covered by this code in
ScrollPaneSkin:
if (optimizeScrolling) {
ApplicationContext.DisplayHost displayHost =
viewport.getDisplay().getDisplayHost();
ApplicationContext applicationContext =
displayHost.getApplicationContext();
optimizeScrolling = (applicationContext instanceof
DesktopApplicationContext
|| (displayHost.getPeer().canDetermineObscurity()
&& !displayHost.getPeer().isObscured()));
}
Can you apply the following patch (attached - applies to the code in trunk),
and see what the Alert says when you scroll the text area in the kitchen
sink demo to reproduce the problem? Also can you open the Java console and
record all the system properties that it spits out (I think you type 's'...
it tells you what to type)?
Much appreciated!
-T
scrollPane
On Thu, Jun 18, 2009 at 4:14 PM, Philippe Lhoste <Ph...@gmx.net> wrote:
> On 18/06/2009 03:58, Greg Brown wrote:
>
>> Sorry it took so long to follow up on this. I didn't see the attachments,
>> but I tried to reproduce this myself in Safari on Windows. In Safari 4, same
>> OS/JVM version, I couldn't reproduce the problem. Any chance you could try
>> upgrading to Safari 4 and see if it still happens?
>>
>
> I can reproduce this on Opera 9.26 (yes, that's old too...), IE6 (I keep
> them for Web testing...), and yes, I can open the page in Firefox 3.0 today,
> so in this browser too.
>
> I have an old graphics card (NVIDIA GeForce4 MX 4000), if that's relevant.
>
> Screenshots at:
> http://imagebin.ca/view/xykAeRui.html
> http://imagebin.ca/view/cYI13W34.html
> http://imagebin.ca/view/rA2nQC.html
>
>
> --
> Philippe Lhoste
> -- (near) Paris -- France
> -- http://Phi.Lho.free.fr
> -- -- -- -- -- -- -- -- -- -- -- -- -- --
>
Re: ReadOnly elements and i18n Validators
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 18/06/2009 03:58, Greg Brown wrote:
> Sorry it took so long to follow up on this. I didn't see the
> attachments, but I tried to reproduce this myself in Safari on Windows.
> In Safari 4, same OS/JVM version, I couldn't reproduce the problem. Any
> chance you could try upgrading to Safari 4 and see if it still happens?
I can reproduce this on Opera 9.26 (yes, that's old too...), IE6 (I keep
them for Web testing...), and yes, I can open the page in Firefox 3.0
today, so in this browser too.
I have an old graphics card (NVIDIA GeForce4 MX 4000), if that's relevant.
Screenshots at:
http://imagebin.ca/view/xykAeRui.html
http://imagebin.ca/view/cYI13W34.html
http://imagebin.ca/view/rA2nQC.html
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
>>> Safari 3.1.2, Java 1.6.0_13, Windows XP Pro SP3, demo on your site.
>
> Did you received the attached images? I don't see them on the ML
> message I received. If not, I can upload them somewhere.
Sorry it took so long to follow up on this. I didn't see the
attachments, but I tried to reproduce this myself in Safari on
Windows. In Safari 4, same OS/JVM version, I couldn't reproduce the
problem. Any chance you could try upgrading to Safari 4 and see if it
still happens?
Re: ReadOnly elements and i18n Validators
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 16/06/2009 01:07, Greg Brown wrote:
>>> Can you send a screen shot?
>>
>> Safari 3.1.2, Java 1.6.0_13, Windows XP Pro SP3, demo on your site.
Did you received the attached images? I don't see them on the ML message
I received. If not, I can upload them somewhere.
BTW, other use case: when a dialog box shows an error message, it might
be useful to select and copy the text for reporting, etc.
Interesting feature in native Windows dialog boxes: when it is
displayed, you can hit Ctrl+C and you get a copy of the dialog! Example:
---------------------------
Modification du nom d'ordinateur
---------------------------
Le nouveau nom d'ordinateur "Tagada foo bar!" contient des caractères
non autorisés. Les caractères non autorisés incluent ` ~ ! @ # $ ^ & *
( ) = + [ ] { } \ | ; : ' " , < > / et ?
---------------------------
OK
---------------------------
Another example, still on Windows: Alt+Enter on a file in Windows
Explorer to get its properties.
You have a number of labels and read-only fields. The latter looks like
fields, but you can select them and copy them (file type, opened with,
path, etc.). I think these are read-only TextInput.
I know Pivot might be limited by security policy for copy/paste stuff,
but it is useful at least in standalone applications. I use it a lot...
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
> On 15/06/2009 23:10, Greg Brown wrote:
>> Maybe some example use cases would help.
>
> I am thinking of some lengthly (or not) text to be read and perhaps
> copied: instructions, help, etc.
OK. Those are use cases for TextArea, not TextInput. Thanks.
>> Hm. I tried to follow these steps but didn't see any odd behavior.
>> Can you send a screen shot?
>
> Safari 3.1.2, Java 1.6.0_13, Windows XP Pro SP3, demo on your site.
> Oddly enough, I can no longer reproduce the problem on the Table.
Ah, Safari on Windows! I thought you meant OS X. I'll check that out.
Re: ReadOnly elements and i18n Validators
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 15/06/2009 23:10, Greg Brown wrote:
> Maybe some example use cases would help.
I am thinking of some lengthly (or not) text to be read and perhaps
copied: instructions, help, etc.
> Hm. I tried to follow these steps but didn't see any odd behavior. Can
> you send a screen shot?
Safari 3.1.2, Java 1.6.0_13, Windows XP Pro SP3, demo on your site.
Oddly enough, I can no longer reproduce the problem on the Table.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
> I saw some disabled controls that totally forbid user input, which
> is annoying: you cannot scroll them, you cannot select text to copy
> it, etc. In this case, a read-only mode can make sense.
Agreed. TextArea should support an "editable" vs. disabled mode, and
it does (or will, when it is complete). For other components (such as
buttons), it doesn't make sense.
> If your Label supports scrolling and selecting, it might make sense
> as a read-only text input. If disabled TextInput supports it, it is
> indeed perceived as read-only. Otherwise, the read-only mode can be
> interesting.
Label doesn't currently support selection, and probably won't, since
you'll ultimately be able to get the "non-editable but selectable"
behavior from TextArea. I can see what you mean about TextInput, but
I'm still on the fence. Maybe some example use cases would help.
> BTW, I wanted to check against your demos, so I went to the Kitchen
> Sink one. I had to open it in Safari because for some reason it
> freezes my Firefox 3 tonight (it is not the most stable lately).
We currently require Safari, though hopefully this will be fixed when
Snow Leopard is released (see the FAQ: http://cwiki.apache.org/PIVOT/frequently-asked-questions-faq.html)
.
> Anyway, I opened the Text fold, and saw some oddities. Perhaps they
> have been fixed already.
> The Label doesn't allow selecting, which isn't really surprising,
> but the TextArea doesn't allow it either, which is more surprising.
TextArea is still incomplete. That's why there is a big "PREVIEW"
watermark on it in the demo. :-)
> There is another glitch: scroll the demo pane so that the TextArea
> is half hidden by the bottom limit of the applet. Scroll the
> TextArea (with its scroll bar): the scrolled part goes down to the
> lower limit of the applet (including the bottom scroll bar).
Hm. I tried to follow these steps but didn't see any odd behavior. Can
you send a screen shot?
Re: ReadOnly elements and i18n Validators
Posted by Philippe Lhoste <Ph...@GMX.net>.
On 15/06/2009 16:39, Greg Brown wrote:
> FWIW, I don't think it makes sense in TextInput - if you find that you
> need a read-only TextInput, you should probably be using a Label.
> Otherwise, you should probably be disabling your TextInput, so the user
> knows that it is actually a text input.
There might be a difference, although it depends on implementation.
I saw some disabled controls that totally forbid user input, which is
annoying: you cannot scroll them, you cannot select text to copy it,
etc. In this case, a read-only mode can make sense.
If your Label supports scrolling and selecting, it might make sense as a
read-only text input. If disabled TextInput supports it, it is indeed
perceived as read-only. Otherwise, the read-only mode can be interesting.
BTW, I wanted to check against your demos, so I went to the Kitchen Sink
one. I had to open it in Safari because for some reason it freezes my
Firefox 3 tonight (it is not the most stable lately).
Anyway, I opened the Text fold, and saw some oddities. Perhaps they have
been fixed already.
The Label doesn't allow selecting, which isn't really surprising, but
the TextArea doesn't allow it either, which is more surprising.
There is another glitch: scroll the demo pane so that the TextArea is
half hidden by the bottom limit of the applet. Scroll the TextArea (with
its scroll bar): the scrolled part goes down to the lower limit of the
applet (including the bottom scroll bar).
Same problem with the Sortable table. But not the Trees.
--
Philippe Lhoste
-- (near) Paris -- France
-- http://Phi.Lho.free.fr
-- -- -- -- -- -- -- -- -- -- -- -- -- --
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
> My quick 2c: Flex has this kind of thing with editable vs enabled
> and I
> agree they are not the same thing.
Sure, but not all components support the concept of editability. What
would it mean to make a button "not editable"? To me, that means
"disabled". We've provided this functionality where we think it makes
sense (ListView, TableView, TreeView, and TextArea). What other
components could realistically support a distinction between
"editable" and "disabled"?
FWIW, I don't think it makes sense in TextInput - if you find that you
need a read-only TextInput, you should probably be using a Label.
Otherwise, you should probably be disabling your TextInput, so the
user knows that it is actually a text input.
Re: ReadOnly elements and i18n Validators
Posted by Christopher Brind <br...@brindy.org.uk>.
My quick 2c: Flex has this kind of thing with editable vs enabled and I
agree they are not the same thing.
Cheers,
Chris
2009/6/15 Sandro Martini <sa...@gmail.com>
> Hi Greg,
> thanks for the help ... but with your answers i guess there isn't the
> concept of a read-only mode for elements (look at normal objects, not
> disabled, but with selection not changeable by the user) ... is this
> wanted or is a missing feature ?
> For example could i implement this as a simple listener that always
> return without changing the element selection (and maybe in a general
> way, so we can reuse it), without changing components API ?
>
> For this I'm also looking at the read only property of (some) HTML
> Form elements ... and at least for some basic elements could be
> useful, like Text Inputs, etc ...
>
> For a user point of view, disabled means "Not available" , "Not
> applicable", etc, while read-only it's another thing ... and in this
> case for example Substance has optional markers to decorate the
> related fields, making more evident to the user that he/she can't
> modify the value, but can use it like expand it (think at a Combo box)
> etc, while maybe some background logic in the application could update
> its values.
>
> What do you (and others) say ?
>
>
> > Selected state and checked state are maintained independently. It is
> possible for an item > to be checked and not selected, and vice versa.
> Ok, no problem ... i think this could be a little confusing, but for me is
> Ok.
>
>
> >> - in TextInputValidatorTest, in the textinputFloatRange I've seen that
> >> giving inputs in the current Locale all works good, but I haven't find
> >> a way to change the Locale, or to set a different format to validators
> >> ... how can i do this ?
> >
> > Noel may be able to comment on this one.
> Ok, I'll wait his feedback ...
>
> Bye,
> Sandro
>
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
> thanks for the help ... but with your answers i guess there isn't the
> concept of a read-only mode for elements
Sure there is - just not for every component. We support this in
ListView, TableView, TreeView, and TextArea - what other components do
you think might benefit from such a feature?
> For this I'm also looking at the read only property of (some) HTML
> Form elements ... and at least for some basic elements could be
> useful, like Text Inputs, etc ...
What is the use case for making a TextInput read-only, but not
providing a visual cue to the user that it is read-only (i.e.
disabling it)?
> For a user point of view, disabled means "Not available" , "Not
> applicable", etc, while read-only it's another thing ... and in this
> case for example Substance has optional markers to decorate the
> related fields, making more evident to the user that he/she can't
> modify the value, but can use it like expand it (think at a Combo box)
> etc, while maybe some background logic in the application could update
> its values.
>
> What do you (and others) say ?
I think you would need to articulate the use cases for a "read-only
but not disabled" state in any components that don't currently support
this.
Re: ReadOnly elements and i18n Validators
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
thanks for the help ... but with your answers i guess there isn't the
concept of a read-only mode for elements (look at normal objects, not
disabled, but with selection not changeable by the user) ... is this
wanted or is a missing feature ?
For example could i implement this as a simple listener that always
return without changing the element selection (and maybe in a general
way, so we can reuse it), without changing components API ?
For this I'm also looking at the read only property of (some) HTML
Form elements ... and at least for some basic elements could be
useful, like Text Inputs, etc ...
For a user point of view, disabled means "Not available" , "Not
applicable", etc, while read-only it's another thing ... and in this
case for example Substance has optional markers to decorate the
related fields, making more evident to the user that he/she can't
modify the value, but can use it like expand it (think at a Combo box)
etc, while maybe some background logic in the application could update
its values.
What do you (and others) say ?
> Selected state and checked state are maintained independently. It is possible for an item > to be checked and not selected, and vice versa.
Ok, no problem ... i think this could be a little confusing, but for me is Ok.
>> - in TextInputValidatorTest, in the textinputFloatRange I've seen that
>> giving inputs in the current Locale all works good, but I haven't find
>> a way to change the Locale, or to set a different format to validators
>> ... how can i do this ?
>
> Noel may be able to comment on this one.
Ok, I'll wait his feedback ...
Bye,
Sandro
Re: ReadOnly elements and i18n Validators
Posted by Greg Brown <gk...@mac.com>.
> - in ListViewTest I'm not able to set the ListView in a Read-Only mode
> (for example I pre-select some elements by code and them i don't want
> the user to modify this selection, but i could change this by code
> later, for whatever reason), but only in a disabled status.
You could either call this:
listView.setSelectMode(ListView.SelectMode.NONE);
or this:
listView.setEnabled(false);
depending on your use case.
> - in ListViewTest I've seen the setItemChecked method, and related
> method setItemChecked .
> But if i comment the setItemChecked call, i got an
> IllegalStateException, ok.
You need to be sure to call setCheckmarksEnabled() first.
> To select elements in this case now I have to use setSelectedIndex ,
> or more the addSelectedIndex ... but aren't all these methods doing
> the same thing: selecting elements in the list ?
> Maybe could be simpler to have only one method to select elements,
> depending what to do on the SelectMode and Checked flag ?
Selected state and checked state are maintained independently. It is
possible for an item to be checked and not selected, and vice versa.
> - in TextInputValidatorTest, as in the first note here I've seen it's
> not possible to put a Text Input in Read-Only mode ... and maybe all
> other Pivot elements, right ?
You can disable any component via the setEnabled() method.
> - in TextInputValidatorTest, in the textinputFloatRange I've seen that
> giving inputs in the current Locale all works good, but I haven't find
> a way to change the Locale, or to set a different format to validators
> ... how can i do this ?
Noel may be able to comment on this one.