Could you try this with today's build?  I checked in a bunch of stuff
yesterday evening to fix problems with this dialog's rather peculiar
use of PropertyPanel.  

I just tried it and wasn't able to reproduce the problem you're having.

Closing as WORKSFORME - I think my work yesterday fixed this.  Reopen
if you see the problem on today's build.

dev build 200312111900 is the latest release as of today. Which dev
build are you referring to?

200312111900
      ^^
I'm referring to it having been built on the 11th, today being the
12th - but I'm always building my own build, so I don't know exactly
what time it would have been built, and therefore, whether it contains
my fixes or not.  The next one should, though.  My last checkins last
night were around midnight Prague time, I believe.

Anyway, the next one will definitely contain the work I did yesterday.

Still reproducible under dev build 200312141900.

Reassigning to editor.

Inherit checkbox should be disabled by default for DEFAULT syntax. It
is regression. We should fix it to NB 3.6

When constructing ColoringEditorPanel, Inherit checkboxes are
initially disabled for the DEFAULT syntax. However, just a few moments
later, these checkboxes are again enabled as a consequence of
setEnabled(true) invocation on ProperyPanel's CustomEditorDisplayer. Tim

When constructing ColoringEditorPanel, Inherit checkboxes are
initially disabled for the DEFAULT syntax. However, just a few moments
later, these checkboxes are again enabled as a consequence of
setEnabled(true) invocation on ProperyPanel's CustomEditorDisplayer.

Tim, why does CustomEditorDisplayer enable CustomEditor component
together with ALL ITS NESTED SUBCOMPONENTS (including Inherit checkbox
in case of ColoringEditorPanel)????

Isn't it responsibility of each CustomEditor to correctly
enable/disable its subcomponents???

It's a fix for an old bug - enabling and disabling JFileChooser doesn't work right - you 
disable it and its components are still active.  So the requirement was that the 
property panel drill through the entire subtree and disable/enable everything.  Maybe 
I could make it do something less extreme, but not for 3.6.

Suggestion:  The entire design of this dialog is barely sane, and required a bunch of 
hacks to make it work with the new property panel (primarily because changing a 
property causes the parent of the PropertyPanel to replace it while it's setting the 
property).  Wouldn't a more normal Swing implementation have a lot less problems 
than three layers of nested property panels replacing each other on the fly?  Consider 
also that it is *completely* impossible to preserve focus after the user presses enter 
on a color field, because the parent of the color field is replaced with a new 
component that doesn't know about the old one.

Note, you should be able to call setEnabled(false) on the checkbox *after* it is shown 
- the inner component is not created until addNotify(), so that's when the enablement 
is checked.

See also contrib/editorthemes for a much simpler UI for this sort of thing.

One thing I could give you quickly - the ability to do something like
putClientProperty("dontEnableMe", Boolean.TRUE) to get the code that walks the tree 
to not enable your checkbox.  Let me know if you want that, it's a five minute fix.  I 
don't think I can restrict the enabling code to just JFileChoosers because other code 
depends on this working the way it always has (it *has* worked this way since 3.2 or 
so - the difference is the timing of when the inner component is created and installed 
- it was not always created lazily, so the ordering of the enablement calls is different 
now).

Let me know if you want me to take care of it with a client property, and I'll let you 
know when it's ready.

It seemed pretty likely that you'd end up needing it, so I've committed the client 
property code to the trunk.  When you create your checkbox, call

myCheckbox.putClientProperty ("dontEnableMe", Boolean.TRUE)

and the code that walks the component tree will ignore it and its subtree if any.  So 
you should be able to get this fixed and closed quickly.

Tim, I agree that this dialog definitely deserves a deep redesign but
not for 3.6. Anyway, thanks for the info.

Fixed in [maintrunk].

/cvs/editor/src/org/netbeans/modules/editor/options/ColoringEditorPanel.java,v
 <--  ColoringEditorPanel.java
new revision: 1.31; previous revision: 1.30
done

*** Issue 39635 has been marked as a duplicate of this issue. ***

FYI, I am not sure who and when introduced code changing the enable
property in the component tree but it definitely breaks functionality
of almost all customizers of source hierarchy elements (eg issue #39891).

I can reuse the "dontEnableMe" property but from my point of view its
a regression.

Jan,

   I recommend someone open up a TASK for the Netbeans team to clean
up this dialog if things are as bad as Tim reported. This
"dontEnableMe" hack gives me a bad feeling about the sanity of this
entire thing.

FYI, the enablement hack has been around since 3.3.  What changed (and what I just fixed) 
is that PropertyPanel would sync the embedded component's state on initialization.  It will 
now only do that if it has been disabled.  So unless you disable and reenable a 
PropertyPanel in custom editor mode, you won't encounter the problem.

Re the sanity of the whole thing:  The core problem is PropertyPanel - it is a magical class 
that tries to do way too much, with multiple states and modes that have lots of possible 
combinations.  As far as I know, Jarda wrote it so he'd never have to write another line of 
GUI code again.  It's a nice idea - you just pass a Property or a BeanDescriptor to the 
constructor of a component and say "I want an inline editor" or "I want a custom editor", 
"make it read only", "make it write the property when x happens" and the PropertyPanel 
magically fulfils your every wish.  The root problem is that the semantics and behavior of 
inline editors, custom property editors are very different, and trying to shoehorn them into 
the gui component to end all gui components that will just anticipate "the right thing" is 
going to produce reams of corner cases.  Add into that mix the various historical 
permutations of NetBeans property editor extensions and the supremely enigmatic 
PropertyEnv, which can also impact behavior, plus various client properties and non-
normative property hints, and, well...rewriting this thing to use the new PropertySheet's 
infrastructure and be backward compatible has to be one of the hardest things I've ever 
done.

There now are sane, non-public, *separate* classes the new PropertyPanel embeds that 
could make a manageable replacement API for it which could make a reasonable 
replacement for its functionality - they are what the rewritten PropertyPanel embeds to do 
what it does.

End rant.

Verified