> On Apr 27, 2018, at 10:04 , Mark Waddingham via use-livecode
> wrote:
>
> You can't tell what the state of disabled was of a child before the owning
> group's disabled property is set - that's the problem.
>
> Imagine we change this without any regard for backwards compatibility to the
> pr
On 2018-04-27 16:57, Bob Sneidar via use-livecode wrote:
Darned if you do, darned if you don't. I get it. Still, looking at
your example, it begs the question, what was the state of the enabled
property for the individual objects before the parent group was
disabled? The current situation is exac
I ran into this on a card basis. I have a handler that loops thru all controls
and disables(and dims) them so a user can't do anything until some function is
complete and a complementary handler that enables them all. This became a
problem if one of the controls on the card was disabled. To solv
Darned if you do, darned if you don't. I get it. Still, looking at your
example, it begs the question, what was the state of the enabled property for
the individual objects before the parent group was disabled? The current
situation is exactly what your objection describes. :-)
I worked around
On 2018-04-27 08:15, Mark Waddingham via use-livecode wrote:
The 'disabled' property should be effectively computed as the logical
and of all the parent's property values
This should be 'logical or' - i.e. a control is disabled if any one of
its parent controls is. It is 'logical and' for the
On 2018-04-26 19:06, Bob Sneidar via use-livecode wrote:
Hi all.
I have a group that contains a number of objects, buttons, menus,
fuelds and groups. I just noticed that if I disable a group (so that
none of the objects in the group can be interacted with) I get the
desired effect. However when
It was probably driven by the data structure more than anything. To upgrade
enabled from one bit to two everywhere would have been non-trivial
(including the now required parent check for the value).
On Thu, Apr 26, 2018 at 4:59 PM Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote
Or else not inherited.
Bob S
> On Apr 26, 2018, at 14:56 , Brian Milby via use-livecode
> wrote:
>
> For that to work, “enabled” would need to be a triple state inherited
> property.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Plea
For that to work, “enabled” would need to be a triple state inherited
property.
On Thu, Apr 26, 2018 at 4:34 PM Mark Wieder via use-livecode <
use-livecode@lists.runrev.com> wrote:
> On 04/26/2018 12:18 PM, dunbarx via use-livecode wrote:
> > Does it make it more palatable to think about it the ot
Exactly. This is not a point of reason as much as it is a decision someone made
a long time ago about how to treat certain properties of objects within a group
when the same property of the group was modified. Apparently there is a special
case for enabled. Someone decided that enabling a group
On 04/26/2018 12:18 PM, dunbarx via use-livecode wrote:
Does it make it more palatable to think about it the other way around? There
should be no real difference:
You have a group where one button is already enabled, and one already
disabled.
By disabling the group, should the enabled button st
Not while the group is disabled, but then afterwards, yes.
Bob S
> On Apr 26, 2018, at 12:18 , dunbarx via use-livecode
> wrote:
>
> Does it make it more palatable to think about it the other way around? There
> should be no real difference:
>
> You have a group where one button is already
I think this is expected behavior.
If you have a group of three buttons:
1- disable one of them
2- disable the group
3 enable the group
You do get all three buttons enabled. But the thinking is likely along the
lines of: "That guy enabled the group, right? That means enable the group,
which inc
My guess... it is because disabled is not an inherited property. All of the
other examples have been properties that are inherited if not explicitly
set. As such a decision was made that setting the enabled property on a
group effects all objects in the group.
__
Does it make it more palatable to think about it the other way around? There
should be no real difference:
You have a group where one button is already enabled, and one already
disabled.
By disabling the group, should the enabled button stay enabled?
Craig
--
Sent from:
http://runtime-revolu
On 4/26/2018 2:45 PM, Richard Gaskin via use-livecode wrote:
> So if we proposed a change to do what you and I feel is more logical,
> the current behavior was put into place long enough ago that we'd now
> have to think about compatibility issues. :(
Bummer :-(
I must admit I have never knowingl
I suppose a better example would be setting the backgroundColor of a group to
blue. Should ALL the objects backgroundColor also be set to blue? If not, then
why the disabled property?
Bob S
> On Apr 26, 2018, at 11:50 , Bob Sneidar via use-livecode
> wrote:
>
> You may be correct. This mig
You may be correct. This might be the expected behavior. But I am not convinced
by the logic. It would be like saying that by dying my hair orange, I obviously
wanted all the hair on my body to also be orange, or that I obviously wanted
all my children's hair to be orange. Or that by locking me
Paul Dupuis wrote:
> On 4/26/2018 1:06 PM, Bob Sneidar via use-livecode wrote:
>> Hi all.
>>
>> I have a group that contains a number of objects, buttons, menus,
>> fuelds and groups. I just noticed that if I disable a group (so
>> that none of the objects in the group can be interacted with) I
>>
i would say this is expected behavior.
If you disable a control in a group, and then enable the group, LC assumes
you want to, er, enable the group, and that means all members of that group.
So as you mentioned, make a gadget that stores the states of all the
members, and resets when the group is
On 4/26/2018 1:06 PM, Bob Sneidar via use-livecode wrote:
> Hi all.
>
> I have a group that contains a number of objects, buttons, menus, fuelds and
> groups. I just noticed that if I disable a group (so that none of the objects
> in the group can be interacted with) I get the desired effect. Ho
Hi all.
I have a group that contains a number of objects, buttons, menus, fuelds and
groups. I just noticed that if I disable a group (so that none of the objects
in the group can be interacted with) I get the desired effect. However when
re-enabling the group, it *ALSO* re-enables ALL the obj
22 matches
Mail list logo
