That's what isBlocked() does.
On Oct 8, 2011, at 7:23 AM, DreamTangerine wrote:
> A quick thought and question :
>
> Why not implement isEnabled() using parent isEnabled() ?
>
> public boolean isEnabled() {
>
> if (null == getParent())
> return enabled;
> else
> return getParent().isEnabled() && enabled ;
> }
>
> or maybe with another name isRecursiveEnabled().
>
> Just a thought.
>
> DreamTangerine.
>
> On sáb, 2011-10-08 at 10:10 +0200, Noel Grandin wrote:
>> On Sat, Oct 8, 2011 at 01:49, Bill van Melle (Commented) (JIRA)
>> <[email protected]> wrote:
>>> In particular, it is important that setting enabled to true for the
>>> container not suddenly enable children that had been disabled befOre the
>>> container was >disabled.
>>>
>>
>> This is what makes any solution extremely hard. What happens if I do this:
>> container.setEnabled(false);
>> child1.setEnabled(false);
>> container.setEnabled(true);
>>
>> What is the right set of children to re-enable?
>> There is no right answer.
>>
>> I do not believe that we can build behaviour that will satisfy all use-cases.
>> The best we can do is to provide some tools to make it easier to
>> achieve various ends.
>>
>> To that end, my proposed solution is:
>> (1) setEnabled(boolean) does what it does now
>> (2) setEnabledRecursive(boolean) is defined at the Container level,
>> walks all the way down it's tree, affecting every element.
>>
>> If you want behaviour different from this, you will have to override
>> setEnabled() and setEnabledRecursive() and implement your own logic.
>>
>> Anything else is simply not going to satisfy all users. I know - I've
>> had this discussion before on the SwingX mailing list.
>>
>> -- Noel Grandin
>>
>
>
