Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread Bindable Control ReadOnly Design
Fri, May 8 2015 7:21 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

I've had some reports of issues with assigning values to the Text property
of edit controls when ReadOnly=True for those controls, and I wanted to get
some feedback here before the final release.

The issue here is how to handle code changes via code, not user changes.
The general design of the bind-able controls is that regardless of whether
they are data-bound or not, they should behave the same way with respect to
being editable and how they trigger change events.  In addition, they should
behave the same way, regardless of whether modifications are made via code,
or by the user.

Right now, the design is that setting the Text property via code will check
the ReadOnly property, and reject the modification if ReadOnly=True.  Also,
the OnChanged event *will* fire when the Text property is modified via code.
The idea here is that the control should behave in a consistent manner, and
should allow the developer to hook into the changes in one place (OnChanged)
in order to do any further processing in the event that the control is
changed.

This does pose some issues for the developer, though.  So, I'm considering
moving the design back to more like what the VCL does: separate behaviors
for in-code modifications vs. user modifications in terms of read-only, but
with the OnChanged event still firing for all changes.

Any viewpoints ?

Thanks,

Tim Young
Elevate Software
www.elevatesoft.com


Fri, May 8 2015 7:31 AMPermanent Link

Matthew Jones

Tim Young [Elevate Software] wrote:

>  setting the Text property via code will check the ReadOnly property,
> and reject the modification if ReadOnly=True

I'd say that was not a good thing. In code, I need to be able to set it
to whatever I want. I often use Read-only edit boxes to allow the user
to copy and paste something, without editing. Basically, the Read-only
setting is a "stop the user messing with it" indicator only IMO.

The event doesn't matter so much, as you can either ignore it using a
flag, or manually trigger it. Both ways around annoy me at times,
depending on how much my code reacts to the changes made, but neither
is terrible.
Fri, May 8 2015 8:37 AMPermanent Link

Chris Holland

SEC Solutions Ltd.

Avatar

Team Elevate Team Elevate

Hi Tim,

I am used to ReadOnly preventing the end user from editing but still
being able to set the value in code and have the OnChanged event
triggered. This would be my preferred option.

Chris Holland
[Team Elevate]

On 08/05/2015 12:21, Tim Young [Elevate Software] wrote:
> I've had some reports of issues with assigning values to the Text
> property of edit controls when ReadOnly=True for those controls, and I
> wanted to get some feedback here before the final release.
>
> The issue here is how to handle code changes via code, not user changes.
> The general design of the bind-able controls is that regardless of
> whether they are data-bound or not, they should behave the same way with
> respect to being editable and how they trigger change events.  In
> addition, they should behave the same way, regardless of whether
> modifications are made via code, or by the user.
>
> Right now, the design is that setting the Text property via code will
> check the ReadOnly property, and reject the modification if
> ReadOnly=True.  Also, the OnChanged event *will* fire when the Text
> property is modified via code. The idea here is that the control should
> behave in a consistent manner, and should allow the developer to hook
> into the changes in one place (OnChanged) in order to do any further
> processing in the event that the control is changed.
>
> This does pose some issues for the developer, though.  So, I'm
> considering moving the design back to more like what the VCL does:
> separate behaviors for in-code modifications vs. user modifications in
> terms of read-only, but with the OnChanged event still firing for all
> changes.
>
> Any viewpoints ?
>
> Thanks,
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>
>
Fri, May 8 2015 9:04 AMPermanent Link

Walter Matte

Tactical Business Corporation

Tim,

I'm with Chris - this is VCL behaviour.

I am used to ReadOnly preventing the end user from editing but still
being able to set the value in code and have the OnChanged event
triggered. This would be my preferred option.


Is this may be what you are referring to currently - the behaviour I see -  CheckBox the Read Only TRUE (Build 7 current) unbound and SelectedState is ssSelect. - looks fine in design - runtime shows - ssIndeterminate.


Walter
Fri, May 8 2015 9:09 AMPermanent Link

Doc

Chris Holland wrote:

I am used to ReadOnly preventing the end user from editing but still
being able to set the value in code and have the OnChanged event
triggered. This would be my preferred option.
________________________________________________
Yes, I see it that way, too,
I don't see much sense in preventing a control from being changed by my own code.
Fri, May 8 2015 9:30 AMPermanent Link

Raul

Team Elevate Team Elevate

On 5/8/2015 7:21 AM, Tim Young [Elevate Software] wrote:
> Right now, the design is that setting the Text property via code will
> check the ReadOnly property, and reject the modification if
> ReadOnly=True.

I'd still like to be able to set the value when read-only thru code
(without having to wrap it in calls to unset readonly and set it back).

In delphi we do use read-only edit fields fair bit (same reason often as
Matthew  so user can copy) and also have cases where the state might get
toggled runtime thru code (i.e. option A vs option b and then some
fields become read-only). I guess what i'm saying is that the extra
wrapping would be PITA and result in some (early) bugs likely.


> Also, the OnChanged event *will* fire when the Text
> property is modified via code. The idea here is that the control should
> behave in a consistent manner, and should allow the developer to hook
> into the changes in one place (OnChanged) in order to do any further
> processing in the event that the control is changed.

OK with that (as long as documented in manual Smile


> This does pose some issues for the developer, though.  So, I'm
> considering moving the design back to more like what the VCL does:
> separate behaviors for in-code modifications vs. user modifications in
> terms of read-only, but with the OnChanged event still firing for all
> changes.

My vote goes for this - allow value change in code.

Raul
Fri, May 8 2015 10:44 AMPermanent Link

Walter Matte

Tactical Business Corporation


Also - If it is not bound and read only - I hope we can still alter the control state in code.

Walter
Fri, May 8 2015 6:47 PMPermanent Link

Steve Gill

Avatar

<< I am used to ReadOnly preventing the end user from editing but still
being able to set the value in code and have the OnChanged event
triggered. This would be my preferred option.>>

I would also prefer this.

= Steve
Image