how to automatically disable editing (except navigation widgets: tabs / scrollbars)?.

[Lobo]

I have many editable windows, which allow users to edit all kind of data, and which contain many different (unknown) components of all types (from simple ones like edittext / combobox / radiobutton / checkbox, to complex ones like editable grids).

I would like, at a certain point (based on certain conditions), to automatically _disable_ editing in specific editable windows but still keep the 'navigation' components active (i.e. still being able to use tabs and scrollbars in order to navigate data but not change it).

In summary, I need to change a window (with many different types of components) from editable to read-only (but keeping navigation controls active) in an automatic way based on conditions.

Is there an easier way than coding script to iterate and change the 'enabled' property for all subviews?.

I'm using OL 4.0.7.

Any ideas? - many thanks.

[rcyeager]

I would use constraints on each of the views that controls their enabled state based on whatever condition you need. Something like:


<class name="myClass">
<attribute name="myCondition" value="1" type="number"/>

<button enabled="${classroot.myCondition == 1}">
<edittext enabled="${classroot.myCondition == 1}">

<button enabled="${classroot.myCondition == 1 || classroot.myCondition == 2}">
<edittext enabled="${classroot.myCondition == 1 || classroot.myCondition == 2}">

</class>


In this manner, setting the "myCondition" attribute to certain values determines which controls are enabled.

Robert
http://www.qrowd.com
http://www.cooqy.com

[Lobo]

Thanks, but I hoped to avoid this (using constraints in every individual component), because it's my understanding that constraints are too 'expensive', and my app is very big with many editable windows (each with many editable components).

But I guess there's no other option, right?.

Many thanks for your feedback.

[rcyeager]

Well, there are different types of expense to any solution:

1. Memory/size expense
2. Runtime/performance expense
3. Programmer/development time expense (construction and maintenance)

The constraint approach as I understand it minimizes #3 but increases #2. #1 is not so much impacted, versus alternatives to get the same behavior...depends on how well the OL compiler generates code vs. your own home-brewed alternative, though.

A script-based approach that went element-by-element through the view hierarchy would increase #3 and possibly #2 and #1, depending on how smartly one could replace the constraint-generated code with your own algorithm. I wouldn't want to maintain that code, especially when screen designs change...

For me, I would try the constraint-based approach and see how well the app performs. The benefits of constraints (ease of development and maintenance) far outweigh any other expense IMO. If performance is not acceptable, I would then convert constraints into custom code, but in a manner that can hopefully be maintained while allowing the screen design to change.

Regards,

Robert
http://www.qrowd.com
http://www.cooqy.com

[Lobo]

Robert,

I'll certainly consider these options.

Thanks again for your input.

Lobo