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.
040726, 1.5.0 b59, Ocean. Had a form open with a GridBagLayout. Selected the Grid Y property. Shows the number "7" and also a pulldown arrow (with "Relative" as an option). I can give focus to the text part and type e.g. "6" but then hitting Enter does nothing. There is no apparent way to change the value from the property sheet.
What look and feel? I did exactly what you describe last night to create a screen shot of some problems for Apple, and it worked as it should.
Ocean, as I said.
I can't reproduce this at all, tried it on Ocean, b59. Can you reproduce this when you create a new form? Wondering if maybe this was one of the older form files in our codebase and perhaps the form editor isn't dealing well with it.
Confirming and clarifying in b60 / Ocean, 040729 custom build. I create a new JPanel form. Set layout to GBL. Drop 4 labels onto it. Open GB customizer, arrange them in a 2x2 grid by dragging them into place. Close customizer. In property sheet, if I select any of the labels, I can click on the value area of any of the properties "Grid X", "Grid Y", "Grid Width", or "Grid Height", and I get a blinking caret and the existing text is selected for me. However *no* keystrokes are registered in the temporary text field. Typing any letters or numbers to replace the existing text; Backspace to delete it; even Escape to cancel editing - all do nothing. I can only click with the mouse on the name area again to cancel editing and leave the value as it was. Changing the existing value to one of "Relative" or "Remainder" with the mouse & pulldown works fine. If I am on one of these rows, pressing Space selects the text field (does not post the pulldown) but then, again, no other keys do anything. All other properties, both plain text and plain pulldown, seem OK. Seems to be a problem with the editable pulldown style.
Do you have an earlier JDK 1.5 build you can try it in?
Just 1.5.0 b59 and 1.4.2_04, though I could download others if necessary. Why do you ask?
Because it works fine elsewhere.
"Elsewhere" meaning what? Have you tried with b60 / Ocean? If you want me to try different JDKs, different builds, different window managers, etc., you have to tell me what...
1.4.2 on mac
Problem seems to be in CleanComboUI (inherits from BasicComboUI to avoid doubled borders in the property sheet) - it's used for GTK and Metal. Something has evidently changed in BasicComboUI since 1.4. I'll try to figure out what.
I've narrowed it down to a one-line fix - delete line 302 of ComboInplaceEditor - so it's not the custom UI at all. What's odd about it is that all it does is call getEditor().getEditorComponent().requestFocus() after addNotify() is called on the combo box, if it is editable - a perfectly reasonable thing to do, and needed at least in 1.4. Will need to see if the problem is also present in 3.6 - I think it will be, and that would mean all editable combo properties are broken for users of 3.6 on JDK 1.5, at least if they use Metal L&F or GTK. If so, it should be filed as a JDK bug, probably pretty high priority. I have a demo app that exhibits the problem. The culprit seems to be the fancy new code for auto-selecting items based on partial typing.
Fixed. Will check if the problem appears on 3.6 as well. Checking in ComboInplaceEditor.java; /cvs/openide/src/org/openide/explorer/propertysheet/ComboInplaceEditor .java,v <-- ComboInplaceEditor.java new revision: 1.25; previous revision: 1.24 done
*** Issue 48898 has been marked as a duplicate of this issue. ***
Need some opinions on this issue. I've talked cursorily with the Swing team; possibly this could be fixed in Swing in 1.5.0_01 or 1.5.1 (since the code worked fine in 1.4). But this issue does mean that the GridBagCustomizer, etc. are broken in 3.6 with JDK 1.5. The bug is partly ours, in that the requestFocus was superfluous, and partly Swing's, since calling requestFocus shouldn't break keyboard input, and the code worked in 1.4. Options: - File a *very* late high priority bug against 1.5 - File a normal priority bug against 1.5 and push to get the fix in 1.5.0_01 (I do have a test case almost finished) - Respin the bits for 3.6 as 3.6.1 with this bugfix (and probably the Ant deadlock bugfix)
Well I think the third option is the best, but I doubt we can justify spending time on it. Failing that, the second makes sense. The first is probably out of the question.
Yeah, I was thinking 2 was the way to go. Pity, after backporting the 4.0 winsys to 3.6 for the Bow team last week, we actually have a pretty nice potential 3.6.1 release. Now, if we could just slip 4.0 again, we could justify it :-)
no further comments - closing