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.
1. Go to Tools > Option > Keymap 2. Select "Replace" and type new Shortcut "Ctrl+Shift+O", WITHOUT DESELECTING Shortcut area press "Ok" >> Option dialog is closed and "Lengthy operation in progress" message dialog occures, which don't react on closing and blocks over NetBeans controls and have never done. So the only one solution I know is to kill NetBeans using Task manager. Of course all unsaved changes in projects have not been saved. Product Version: NetBeans IDE 7.4 RC2 (Build 201309252201) Java: 1.7.0_40; Java HotSpot(TM) Client VM 24.0-b56 Runtime: Java(TM) SE Runtime Environment 1.7.0_40-b43 System: Windows 7 version 6.1 running on x86; Cp1252; en_US (nb)
Created attachment 140543 [details] step_01
Created attachment 140544 [details] step_02
Reproducible always if there is shortcut conflict
and it works in NB 7.3.1 Milutin, please evaluate.
*** Bug 237425 has been marked as a duplicate of this bug. ***
This would be tough to fix; a background thread may use DialogDisplayer.notify() to prompt the user which in this case conflicts with RunOffEDT implementation.
In previous version, all unconfirmed changes (e.g. used didn't press enter after changing shortcut) was ignored. Can be this behavior restored?
*** Bug 237741 has been marked as a duplicate of this bug. ***
*** Bug 238103 has been marked as a duplicate of this bug. ***
A functioning workaround is to clear the existing keybind, save changes with OK, then return the the screen and rebind the function to the new keybind. Applying changes after clearing a keybind and attempting to remap that keybind will still cause the lengthy operation dialogue.
(In reply to Jiri Prox from comment #7) > In previous version, all unconfirmed changes (e.g. used didn't press enter > after changing shortcut) was ignored. Can be this behavior restored? The behaviour (in keymap opts) is the same as in the previous release. But the option save itself runs now in non-EDT thread (this was the change). Potentially all options, that ask for confirmation on save are affected. I've somewhat restored the behaviour in that conflicts are not saved if the unconfirmed shortcut is saved using OK / Apply, but it leads to an inconsistency or reopening an older defect. Even watching out for focus lost on the input line (-> perform checks, display dialog and store the input line's contents into the model) was useless during the testing: once the nested dialog was fired, the event loop received an action performed on the button and the save was initiated. Ultimately the defect's fix leads to a more sophisticated save protocol between Options dialog infrastructure and individual panes - all pending actions must be somehow given the chance to finish. Fixed in trunk in rev http://hg.netbeans.org/jet-main/rev/2b74af6c46ca
verified in the trunk
*** Bug 238452 has been marked as a duplicate of this bug. ***