Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2008-02

Opinions required on what the ReadOnly property should do for LCL controls.

22 messages · 10 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Gerard N/A

There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861.
It's not a technical discussion, it's more about what ReadOnly should and shouldn't do.

See. http://bugs.freepascal.org/view.php?id=10861

The list is probably a better place to discuss this, so please read the report and give your opinion here.

Regards,

Gerard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080221/5d10fb4f/attachment.html

Reply by email

Marius
to Gerard N/A
Gerard N/A wrote 9 lines
There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's not a technical discussion, it's more about what ReadOnly should and shouldn't do. See. http://bugs.freepascal.org/view.php?id=10861 The list is probably a better place to discuss this, so please read the report and give your opinion here.

http://www.reference.com/search?r=13&q=Read-only

Readonly = Not writable = Cannot change the contents of what is supposed to be edited in that particulary component. So when readonly we are not allowed to change the contents by entering text or changing the text indirect via a popup or any other dialog (its could still be allowed to show the popup).

But i see Vincents point also, there must be a way for advanced components to disallow direct character input and only accept dialog input. For example a TRzSpinEdit with a property AllowKeyEdit. But IMHO it is just a luxurious version of disallowing keys to avoid manual entry/mistakes.

Greetings,
Marius

Reply by email

Graeme Geldenhuys
to Marius
Marius wrote 8 lines
http://www.reference.com/search?r=13&q=Read-only Readonly = Not writable = Cannot change the contents of what is supposed to be edited in that particularly component. So when readonly we are not allowed to change the contents by entering text or changing the text indirect via a popup or any other dialog (its could still be allowed to show the popup).

And if a component is ReadOnly, you are still allowed to change the values from code.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

svaa
to Gerard N/A: There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's…

Hello:

For me there is no doubt. When I set a control as readonly, I expect that the user won't be able to change fact, years ago I hacked rxlib to avoid pop a list when they where readonly. Particulary if they are attached to a database, it's confusing for the user to change it clicking the button but updating nothing. The downside is that they won't be able to show the calendar, but I think it is better than confusing user. If the popped calendar could show clearly that is not changeable, it would be the best, but a low priority enhacement. By the way, when I say TDateTimeEdit, I mean any control with a combo etc.

Anyhow, if you want people see that a control is not usable, it is better to assign enable:=false. The pity of disabled controls it that they are not easily readable.

Sometimes I think that there should be three colors to inform the user of the state of the control: enabled, disabled and readonly. Long time ago I played with the idea of changing the Dataware controls to have a yellow background when they where not editable (because they were readonly or because the TDatasource was not autoedit or because the underlaying table was readonly.)

Just my 0.25 cents.

Reagards
Santiago A.

Show quoted text 21 lines
There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's not a technical discussion, it's more about what ReadOnly should and shouldn't do. See. http://bugs.freepascal.org/view.php?id=10861 The list is probably a better place to discuss this, so please read the report and give your opinion here. Regards, Gerard. ------------------------------------------------------------------------ _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus ------------------------------------------------------------------------

Reply by email

Inoussa OUEDRAOGO
to John

2008/2/22, John :

Show quoted text 67 lines
svaa wrote: Hello: For me there is no doubt. When I set a control as readonly, I expect that the user won't be able to change it at all. In fact, years ago I hacked rxlib to avoid pop a list when they where readonly. Particulary if they are attached to a database, it's confusing for the user to change it clicking the button but updating nothing. The downside is that they won't be able to show the calendar, but I think it is better than confusing user. If the popped calendar could show clearly that is not changeable, it would be the best, but a low priority enhacement. By the way, when I say TDateTimeEdit, I mean any control with a combo etc. Anyhow, if you want people see that a control is not usable, it is better to assign enable:=false. The pity of disabled controls it that they are not easily readable. Sometimes I think that there should be three colors to inform the user of the state of the control: enabled, disabled and readonly. Long time ago I played with the idea of changing the Dataware controls to have a yellow background when they where not editable (because they were readonly or because the TDatasource was not autoedit or because the underlaying table was readonly.) Just my 0.25 cents. Reagards Santiago A. +1 I usually change the colour or background colour of a control if it *always* readonly, it would be great to have an easy way to do it. I probably tend to disable a control if its mode changes, but it can still be useful to distinguish between "valid, but read only" and "invalid in this context". I think the difference between the two views depends on whether you see the TDateEdit as two controls ( in which case I agree with Vincent) or a single control, in which case I agree with Gerard. If it were two controls, you make the edit box readonly (to keystrokes), but the button is changing it programatically. But if it is a single control, readonly = readonly = readonly - no user changes of any kind. As it appears to only a single control - you can't disable the button without disabling the whole control - I think I have to agree with Gerard cheers, John Sunderland There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's not a technical discussion, it's more about what ReadOnly should and shouldn't do. See. http://bugs.freepascal.org/view.php?id=10861 The list is probably a better place to discuss this, so please read the report and give your opinion here.

IMHO, whenever "ReadOnly=True", user should not be able to modify the value, be it by
the text edit or by the button. I use code like
[code]
for i := 0 to Pred(ContrloCount) do begin

  ct := Control[i];
  if IsPublishedProp(ct,'ReadOnly') then
    SetProp(ct,'ReadnOnly',False);

end;
[/code]
to be sure the user cannot modify any value.
Example : On a Edit form, I want the user to be able to modify certain properties ( "color of your car") depending on the value of other properties ( "Own a car" ).

I second the idea of a "DirectEdit" property.

Best regards.

Inoussa O.

Reply by email

Inoussa OUEDRAOGO
to Inoussa OUEDRAOGO

2008/2/22, Inoussa OUEDRAOGO :

Show quoted text 85 lines
2008/2/22, John : > > svaa wrote: > Hello: > > For me there is no doubt. When I set a control as readonly, I expect > that the user won't be able to change it at all. > > In fact, years ago I hacked rxlib to avoid pop a list when they where > readonly. Particulary if they are attached to a database, it's confusing > for the user to change it clicking the button but updating nothing. The > downside is that they won't be able to show the calendar, but I think it > is better than confusing user. If the popped calendar could show clearly > that is not changeable, it would be the best, but a low priority > enhacement. By the way, when I say TDateTimeEdit, I mean any control > with a combo etc. > > Anyhow, if you want people see that a control is not usable, it is > better to assign enable:=false. The pity of disabled controls it that > they are not easily readable. > > Sometimes I think that there should be three colors to inform the user > of the state of the control: enabled, disabled and readonly. Long time > ago I played with the idea of changing the Dataware controls to have a > yellow background when they where not editable (because they were > readonly or because the TDatasource was not autoedit or because the > underlaying table was readonly.) > > Just my 0.25 cents. > > Reagards > Santiago A. > > +1 > > I usually change the colour or background colour of a control if it > *always* readonly, it would be great to have an easy way to do it. I > probably tend to disable a control if its mode changes, but it can still be > useful to distinguish between "valid, but read only" and "invalid in this > context". > > I think the difference between the two views depends on whether you see the > TDateEdit as two controls ( in which case I agree with Vincent) or a single > control, in which case I agree with Gerard. > > If it were two controls, you make the edit box readonly (to keystrokes), > but the button is changing it programatically. But if it is a single > control, readonly = readonly = readonly - no user changes of any kind. > > As it appears to only a single control - you can't disable the button > without disabling the whole control - I think I have to agree with Gerard > > cheers, > John Sunderland > > > > > > There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis > report 10861. > It's not a technical discussion, it's more about what ReadOnly should > and shouldn't do. > > See. http://bugs.freepascal.org/view.php?id=10861 > > The list is probably a better place to discuss this, so please read > the report and give your opinion here. IMHO, whenever "ReadOnly=True", user should not be able to modify the value, be it by the text edit or by the button. I use code like [code] for i := 0 to Pred(ContrloCount) do begin ct := Control[i]; if IsPublishedProp(ct,'ReadOnly') then SetProp(ct,'ReadnOnly',False); end; [/code] to be sure the user cannot modify any value. Example : On a Edit form, I want the user to be able to modify certain properties ( "color of your car") depending on the value of other properties ( "Own a car" ).

So in edit style : "Readonly =False", but "Enable" depends on the state of the object.
In view style, "ReadOnly = True", the user can just view the item;

Best regards.

Inoussa O.

Reply by email

Michael Van Canneyt
to Gerard N/A: There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's…
Gerard N/A wrote 9 lines
There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report 10861. It's not a technical discussion, it's more about what ReadOnly should and shouldn't do. See. http://bugs.freepascal.org/view.php?id=10861 The list is probably a better place to discuss this, so please read the report and give your opinion here.

RX has a property 'DirectInput' for its TDateEdit and friends. It controls whether the user can type or is forced to use the button (dialog).

If you have DirectInput, then ReadOnly should disallow typing and also disallow the use of the button.

Using enabled for 'readonly' is not correct, since the control is shown differently (grayed-out) when it is not enabled, and that is not the intention.

Michael.

Reply by email

Vincent Snijders
to Michael Van Canneyt
Michael Van Canneyt wrote 23 lines
On Thu, 21 Feb 2008, Gerard N/A wrote: > There's a discussion going on about TDateTimeEdit.ReadOnly in Mantis report > 10861. > It's not a technical discussion, it's more about what ReadOnly should and > shouldn't do. > > See. http://bugs.freepascal.org/view.php?id=10861 > > The list is probably a better place to discuss this, so please read the > report and give your opinion here. RX has a property 'DirectInput' for its TDateEdit and friends. It controls whether the user can type or is forced to use the button (dialog). If you have DirectInput, then ReadOnly should disallow typing and also disallow the use of the button. Using enabled for 'readonly' is not correct, since the control is shown differently (grayed-out) when it is not enabled, and that is not the intention.

I am convinced. Gerard, can you enhance the patch with a DirectInput property?

Vincent

Reply by email

Unknown author

What you say is right for single component but not for composite components like edit&button. In fact you cannot type on a button but you can do that on a edit.
Due to different date format (short long and
so on) the original idea was to select a date by a calendar and not by typing. In this way the user bypass the date format. Regards,
Salvatore

---------------------------------------------------------------------- Gerard Visent - 2008-02-21 16:49
---------------------------------------------------------------------- Salvatore:

No, I dind't confuse ReadOnly with Enabled.

From the VCL

ref.:

TControl.Enabled: Use Enabled to change the availability of the control to
the user. To disable a control, set Enabled to false. Disabled controls
appear dimmed. If Enabled is false, the control
ignores mouse, keyboard,
and timer events.
To re-enable a control, set
Enabled to true. The control is no longer
dimmed, and the user can use
the control.

TCustomEdit.ReadOnly: To restrict the edit control to display only, set
the ReadOnly property to true. Set ReadOnly to false to allow the contents
of the edit control to be edited.

Setting
ReadOnly to true ensures that the text is not altered, while still allowing the user to select text. The selected text can then be manipulated
by the application, or copied to the Clipboard.

Many other
components or classes (TDBGrid, TColumn, TEdit, TField, All DB controls
that allow editing) also have a ReadOnly property wich is used in the
same way.
This way, if you want to lock some fields on a form while others can be
edited (a very common behaviour in many apps), you just set them to
ReadOnly.
If we go the other way, not only will you have to
set enabled for some
controls and not for others, but for those that
are disabled the user won't
be able to select the text and copy.

Now,
you can always say that we don't have to abide to VCL compatibility or
even common sense <g>

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: RX has a property 'DirectInput' for its TDateEdit and friends. It controls whether the…
Michael Van Canneyt wrote
Using enabled for 'readonly' is not correct, since the control is shown differently (grayed-out) when it is not enabled, and that is not the intention.

I agree, 'readonly' is a different state to 'enabled=false'. Maybe all components should point a little icon over a readonly component, like Gnome's Nautilus does? :) See attached screenshot.

I have never seen a widgetset do that on components, but wonder how the users would react to seeing that? Umm...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readonly.png
Type: image/png
Size: 3597 bytes
Desc: not available
Url : http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080222/8cc2e447/attachment.png

Reply by email

Gerard N/A
to Graeme Geldenhuys: I agree, 'readonly' is a different state to 'enabled=false'. Maybe all components should…
Show quoted text 8 lines
I agree, 'readonly' is a different state to 'enabled=false'. Maybe all components should point a little icon over a readonly component, like Gnome's Nautilus does? :) See attached screenshot. I have never seen a widgetset do that on components, but wonder how the users would react to seeing that? Umm...

I like the general idea, but Nautilius icon is everything but clear. I wouldn't know what it means if you haven't told me ;-) Maybe a little lock somewhere would be more clear, but that's a lot of work if you want to make it consistent across all controls.

G.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080222/646a57c3/attachment.html

Reply by email

Gerard N/A
to Unknown author: What you say is right for single component but not for composite components like…

On Fri, Feb 22, 2008 at 11:15 AM, <

Show quoted text 5 lines
wrote: What you say is right for single component but not for composite components like edit&button. In fact you cannot type on a button but you can do that on a edit.

So? a TCustomEditButton is only a TEdit with an additional alternative entry system.
The button+calendar are just helpers to the editor, not the other way around.

Due to different date format (short long and so on) the original idea was to select a date by a calendar and not by typing. In this way the user bypass the date format.

That's where a property like DirectEdit (or whatever you want to call it ) would be handy. You set it to true and the user is forced to use the button+popup dialog to choose a value.

Regards,

Gerard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080222/a31b5852/attachment.html

Reply by email

Unknown author

Gerard N/A ha scritto:

On Fri, Feb 22, 2008 at 11:15 AM,

What you say is right for single component but not for composite

components like edit&button. In fact you cannot type on a button but

you can do that on a edit. So? a TCustomEditButton is only

a TEdit with an additional alternative entry system.

The

button+calendar are just helpers to the editor, not the other way around.
Yes I think so

Due to different date format (short

long and

so on) the original idea was to select a date by a

calendar and not by

typing. In this way the user bypass the date

format.

That's where a property like DirectEdit (or whatever you

want to call it ) would be handy. You set it to true and the user is forced to use the button+popup dialog to choose a value.

OK! it is
better than readonly

Regards, Gerard.

Reply by email

Graeme Geldenhuys
to Gerard N/A: I like the general idea, but Nautilius icon is everything but clear. I wouldn't know…
Gerard N/A wrote 5 lines
I like the general idea, but Nautilius icon is everything but clear. I wouldn't know what it means if you haven't told me ;-) Maybe a little lock somewhere would be more clear, but that's a lot of work if you want to make it consistent across all controls.

You are right, the icon is a bit unclear and can be improved on. As for the position of the icon, it could have certain defaults for each component and customizable by the developer via the Object Inspector.

BUT we forgot a much bigger issue! It's not native behaviour so is a no-no in LCL components. ;-) Maybe I'll add it as a optional setting in fpGUI - I first need to create some mock-ups with Gimp to see how they would look on all widgets.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Vincent Snijders
to Graeme Geldenhuys
Graeme Geldenhuys wrote
BUT we forgot a much bigger issue! It's not native behaviour so is a no-no in LCL components. ;-) Maybe I'll add it as a optional setting in fpGUI - I first need to create some mock-ups with Gimp to see how they would look on all widgets.

Now you have got an unique selling point for fpGUI :-)

Vincent

Reply by email

Alexsander Rosa
to Graeme Geldenhuys: You are right, the icon is a bit unclear and can be improved on. As for the position of…

Read-only is a property that only makes sense in text widgets. It does NOT disable the widget, but prevents the user of changing its text content. It does not make sense for a ListBox or a Button, for example.

2008/2/22, Graeme Geldenhuys :

Show quoted text 34 lines
On 22/02/2008, Gerard N/A wrote: > > I like the general idea, but Nautilius icon is everything but clear. > I wouldn't know what it means if you haven't told me ;-) > Maybe a little lock somewhere would be more clear, but that's a lot of work > if you want to make it consistent across all controls. You are right, the icon is a bit unclear and can be improved on. As for the position of the icon, it could have certain defaults for each component and customizable by the developer via the Object Inspector. BUT we forgot a much bigger issue! It's not native behaviour so is a no-no in LCL components. ;-) Maybe I'll add it as a optional setting in fpGUI - I first need to create some mock-ups with Gimp to see how they would look on all widgets. Regards, - Graeme - _______________________________________________ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ _______________________________________________ Lazarus mailing list http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Atenciosamente, Alexsander da Rosa Linux User #113925 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080222/7ece80f3/attachment.html

Reply by email

Graeme Geldenhuys
to Alexsander Rosa
Alexsander Rosa wrote
Read-only is a property that only makes sense in text widgets. It does NOT disable the widget, but prevents the user of changing its text content. It does not make sense for a ListBox or a Button, for example.

I agree, but it does to most Text Edit and CombBox style components. There are quite a few of them. eg: CalculatorEdit, SpinEdit, FloatEdit, CurrencyEdit, Calendar Date Edit etc... just to name a few.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reply by email

Gerard N/A
to Gerard N/A: Sure. I'll post a new patch this afternoon. G. -------------- next part -------------- An…

It'll be during the weekend, I'm busy for a moment. :-(

Gerard N/A wrote 9 lines
> I am convinced. Gerard, can you enhance the patch with a DirectInput > property? Sure. I'll post a new patch this afternoon. G.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20080222/d763f2c1/attachment.html

Reply by email

svaa
to Graeme Geldenhuys: I agree, but it does to most Text Edit and CombBox style components. There are quite a…

Hi:
(Just a little off topic about TDatetimeEd)

After deep  thoughts about how I use readonly and enabled;-) I have
Concluded this:
enabled:=false > Invisible
readonly:=true > Label

Enabled
When I set a control to enabled:=false, it's because i think the user shouldn't see or care about that control. A common use is speedbuttons . Some times depending upon some selection, some controls have no sense, i.e.some checks or radio buttons disable other controls. For all purposes those controls could be invisible. Why do I disable them instead of setting visible:=false? Most times because there would be a lot of ugly blank spaces (or in autoaligns would move other controls, confusing the user), some times because I'm waiting some data before letting the user fill the disabled controls, and it's not bad to let user see whats going on.

Readonly
I could say that most times I should use a label but I am too lazy. I have made a form to input data, and I want to reuse the same form to display the data. Some times there are controls that I want dynamically set to readonly, contrary to disable the controls, the information shown is relevant for the user, but I don't want him to change it. The only difference with a label is that it looks like a control, so the user knows that in some circumstances he could change the data.

That is what I want to do, but things are not always that easy and clear . When there are controls readonly and not readonly in a form, they look the same so it's confusing for the user. To prevent this, sometimes I change the background to the form's backgound, others I replace it dynamically with label, other times I don't set it readonly but when the user tries to change it I pop message saying why he can't change it. I have seen (but I don't like) chekbuttons disabled, because they must be checked or unchecked compulsorily. I think it is not a good idea, if it is disabled the user could skip it as irrelevant.

Of course, it would be handy a way to show clearly that it is not editable. Unfortunately, most GUI lack of such concept, so we would have to come out with something new, that is seldom a good idea when talking about interfaces. If it is not a very clear "metaphor" instead of helping the user we will confuse him.

Just my 0.10 cents.

Santiago A.

Reply by email