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.
To reproduce the bug: 1. Create JarRecipe, select it in the Explorer, call Properties window 2. Push the "File Filter" sheet button 3. Push "..." button, dialog "File Filter" appears 4. Select ALT-R, push Tab and enter any regular expression in textfield (for example ./html&) and push OK. 5. The sheetbutton becomes empty. 6. Tab to the "File Filter" again and push "Space" Key. Expression "./html&" appears on the sheetbutton. 7. Tab to "..." and open dialog, in the textfield you can see entered expression. 8. Change it for "./java&", push OK. 9. The sheetbutton becomes empty. 10. Again open dialog. The textfield is empty too, not "html" or "java". Note, that all works fine for me if to use mouse. Product Version: Sun One Studio, Standard Edition (Build 030217_1) IDE Version: IDE/1 spec=3.34 impl=030217_1 Operation System: SunOs version 5.8 running on sparc Java: 1.4.0 VM: Java HotSpot(TM) Client VM 1.4.0-b92
Reproduced. This strange behaviour is due to the mess in the implementation of the panel and prop-editor. Probably some update of the value of the regexp is hooked to the wrong event.
It looks like the bug is in openide. I investigated it in detail and I must disregard my previous comment. The PropertyEditor (modules.jarpackager.FilterEditor) operates in both cases (keyboard or mouse) the same - it updates the value of the editor and fires a property change event. The difference is in that in the case the dialog is finished by pressing OK with the mouse, property-change-event is fired by the property editor and as a result of it setValue is called (by the framework) on the filter property. When closing the dialog by pressing enter, the event is fired but no setValue arrives at the property. For clarity, I'm attaching a sample of my debugging outputs to console that illustrate this. when OK is pressed with mouse: ------------------------------- updating value of regexp: ahoj <-- value in the PropEditor updated firing change... <-- PropertyChangeEvent fired filterProperty.setValue( ahoj)<-- setValue on the property ...returned from fire <-- handling of the event finished when Enter is pressed ---------------------- updating value of regexp: johaha <-- value in PropEditor updated firing change... <-- event fired ...returned from fire <-- event handling finished (nothing happened on the property)
Has anyone double checked this in the new property sheet? BTW, possible issue: If you cache the custom editor instance, you need to make sure - if it is displayed a second time - that the last-passed PropertyEnv to attachEnv is the one it believes controls the dialog.
I just tried this with the current trunk/soon-to-be-integrated property panel rewrite branch. I can find no problem with the behavior - the property is updated whether invoked by keyboard or mouse. However: Has this custom editor changed somehow? At least on Windows L&F, there seem to be a few UI problems: - No labels for what the fields are - No focus indication whatsoever (maybe a windows L&F problem?) - the only time you can tell focus is anywhere is when the caret is in the text field
Sorry, meant to close as worksforme, not wontfix.
Closing as worksforme.
verified