But again, the problem with recursively setting the enabled flag is that you blow away any existing state. That's why I think simply painting the disabled state when isBlocked() is true would be preferable.
On Oct 8, 2011, at 1:10 AM, Noel Grandin wrote: > On Sat, Oct 8, 2011 at 01:49, Bill van Melle (Commented) (JIRA) > <j...@apache.org> 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
