Malformed Context Menu in Projects Window

[tomwheeler]

I've noticed a sporadic problem in my platform application. I've got
a fairly complex custom project type which shows maybe 12-15 different
types of nodes. When I right-click one of them (I've noticed this
behavior on at least a few different node types), I sometimes get a
flat gray box instead of the actual context menu I expected. I cannot
reproduce this at will, though it seems to happen more frequently
after I've just done something that adds or removes nodes from my
tree. In any case, right-clicking a second time always shows the
context menu correctly.

Since I have noticed this behavior in my other platform apps or in the
IDE itself, I'm sure that it's a bug in my application. But since I
don't see anything obvious that would cause it, any advice about where
to look would be greatly appreciated.

--
Tom Wheeler
http://www.tomwheeler.com/

[Gregg Wonderly]

This sounds like two threads trying to paint the same component at the same
time. What event processing is your application code involved in? Could it be
that you are changing the menu content dynamically or otherwise causing
"clipping" to clip the paint so that the background is painted the default gray
color and no other painting actually draws because there is a moment that the
menu appears to be empty?

Gregg Wonderly

Tom Wheeler wrote:

[tomwheeler]

I agree that it definitely sounds like threading, though it's not
clear exactly what I might be doing wrong.

There are two types of nodes for which I can reproduce it with some
regularity, and for what it's worth, one of those nodes is a child of
the other one. I just checked the code for getActions(boolean) in
those nodes again and in both cases they're returning a new array
created and populated solely inside that method. I also briefly added
some logging to getActions(boolean) and verified that it's only ever
called from the EDT, even when the malformed menu is shown.

I am updating the icons dynamically based on changes in project state,
so I think I'll have another look at that code.

On Thu, Oct 8, 2009 at 4:47 PM, Gregg Wonderly <address-removed> wrote:

[tomwheeler]

I had another look at that code, though it was inconclusive. There
are several nodes for which I override the getIcon(int) method almost
identically to what's below and call fireIconChange() from the current
thread whenever the state changes, but I find several similar examples
in the NetBeans code base as well.

@Override
public Image getIcon(int type) {
State state = getCurrentState();

String overlayPath = null;
switch (state) {
case IN_PROGRESS:
overlayPath = ICON_PATH_IN_PROGRESS;
break;
case ERROR:
overlayPath = ICON_PATH_ERROR;
break;
case COMPLETE:
overlayPath = ICON_PATH_COMPLETE;
break;
}

Image base = ImageUtilities.loadImage(ICON_PATH_BASE);
if (overlayPath == null) {
return base;
}

Image overlay = ImageUtilities.loadImage(overlayPath);
return ImageUtilities.mergeImages(base, overlay, 0, 0);
}


Other than this, it's seems to be pretty standard node stuff. Since
the threading model of NetBeans APIs can be pretty vague, I'm guessing
that something expects a different thread than it's getting, but it's
sure not obvious what that could be or how I could figure it out for
myself.

On Thu, Oct 8, 2009 at 5:03 PM, Tom Wheeler <address-removed> wrote:
...

[Gregg Wonderly]

I have two annotations that I am starting to use more and more to document such
expectations for EDT usage

@InsideEDT
@OutsideEDT

It has helped for others to see the environment where such annotated methods
should/can be used.

Frameworks that make sure these kinds of things happen are most helpful. In the
end, I almost always have a runInSwing(Runnable) method in my tooling for GUI
applications that I use to manage this issue inside of methods that need both.

If they really do expensive things outside of the runInSwing(), I do go ahead
and use my SyncThread class to make sure that I don't block the EDT with
expensive work if someone calls the method on the EDT.

This is not easily managed stuff in code that has such wide range of usages.

Gregg Wonderly

Tom Wheeler wrote:

[Tim Boudreau]

tomwheel wrote: