This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | IndexedPropertyEditor/ComboInplaceEditor do not properly invoke row specific custom editor | ||
---|---|---|---|
Product: | platform | Reporter: | Michael Frisino <frisino> |
Component: | Explorer | Assignee: | _ tboudreau <tboudreau> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jrechtacek, mstevens, ttran |
Priority: | P1 | ||
Version: | 3.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
testcase Foo.java
IllegalStateException trace DefaultButtonModel trace of problem DefaultButtonModel with latency shows working trace Some patches to try |
Description
Michael Frisino
2004-08-25 06:35:14 UTC
Created attachment 17096 [details]
testcase Foo.java
Created attachment 17097 [details]
IllegalStateException trace
Argghhh, I hate that I cannot edit previous comments: Correction to the test case scenario. Should read as follows; Open NB 3.6 and mount the filesystem with Foo.java Compile it. Select the "Customize Bean" action. This brings up the bean customizer. Select the custom editor for the property "c". This brings up the IndexedPropertyEditor. Add a row. ... rest of instructions are correct. I have read into the report from http://www.netbeans.org/issues/show_bug.cgi?id=10778 and I believe it is orthoganal to the primary problem described here. That is about deadlock issues. I am not seeing deadlock. Furthermore, I am not seeing that warning in our Studio Bow build, perhaps we have already backported some code in prior issuezilla bugs that eliminated the 10778 from our Studio Bow codeline. I worked with Mike on this problem for a couple of days. While Mike was working in the debugger to track down problem I worked on adding some debug printlns into classes like DefaultButtonModel to try and track order of event processing and codepaths to the state changes in the button. As Mike explained, in our problem situation where the custom editor button is useless, we realized that our fireActionPerformed() is never called and we tracked that down to a pathlogic stateMask value change from 13->12. When the 'mouseReleased" event is processed as a <DefaultButtonModel>.setPressed(false) the fireActionPerformed() is never called because the stateMask is '12' instead of '25'. The button only works if the <DefaultButtonModel>.setRollover(true) run previous to the setPressed(false). What our debugger and log debugging efforts shows was that introduction of some latency would yeild a parade of events and codepaths which worked. Without an artificially introduced latency we see out problem. Just like Mike found when setting breakpoints....certain combinations of additional debug println() in DefaultButtonModel could predictably toggle the problem. In other words, the slight slow down causes by some println's would make the problem go away. The fact that we can toggle the problem paints the issue as a Race condition. Again, my debug logging revealed that when the problem occurs we are reaching the <DefaultButtonModel>.setPressed(false) codepath [which should lead to the fireActionPerformed()] WITHOUT a preceeding <DefaultButtonModel>.setRollover(true). Our debug logging tactic was to print the DefaultButtonModel identity, its stateMask value change and the name of the method being entered (e.g. setPressed, setArmed) and on occassion drop a stack trace to see where we were coming from. I will attach some short log file "BAD and GOOD" which highlight the differences in the call stacks. Our observation was from the DefaultButtonModel perspective (which is all I was looking at and as such I may be just looking at collateral from the root cause issue). The difference between the working and not working cases was difference after the initial setPressed(true) call on the DefaultButtonModel. With artifical latency setPressed(true) is followed by a setRollover(true) AND the event processing leading to this mouse event is a dispatch of an AWTEvent to a Window. Without the latency in the case which doesn't work the setPressed(true) is followed by a setArmed(false) AND the event processing leading to this focus event is a dispatch of an AWTEvent to a container....not the Window. A very flimsy guess is that setPressed(true) which comes from a codepath through TreeTable$TreeTableUI$TreeTableMouseInputHandler is racing against something and when a latency is introduced into the system the winner of the race changes. I am only picking on the NB code here because its the only non-AWT/Swing code preceeding the problem (from the DefaultButtonModel perspective). Again all these are observations we found picking away at this problem. They may or may not help you. Created attachment 17137 [details]
DefaultButtonModel trace of problem
Created attachment 17138 [details]
DefaultButtonModel with latency shows working trace
Created attachment 17148 [details]
Some patches to try
BTW, I suspect the button model stuff has to do with focus - that is, clicking the button will give it focus, but there is already a pending focus event for the combo box, which runs afterwards; so losing focus could change the state of the button's model, and also happen between the mouse pressed and mouse released events. Not sure, about that, but there is a bunch of stuff going on when a table cell editor is added, wrt focus, which if added to by the machinations to make combo boxes work properly (as in, you click one combo and its popup opens; click another and its popup opens [in reality there is only one popup in the system]). All of which is easy to do if you write your own UI, but not if you want something that works on all look and feels and works correctly on all of them. BTW, if the patches I provided are sufficient, it would be good to close this issue. Closing. Really closing:-) |