![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder 2 Preview » View Thread |
Messages 1 to 8 of 8 total |
![]() |
Fri, May 8 2015 7:21 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. ![]() | 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 AM | Permanent 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 AM | Permanent Link |
Chris Holland SEC Solutions Ltd. ![]() | 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 AM | Permanent 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 AM | Permanent 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 AM | Permanent Link |
Raul ![]() | 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 ![]() > 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 AM | Permanent 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 PM | Permanent Link |
Steve Gill | << 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 |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |