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.
I'm using a CloneableEditor inside a MultiView. The MultiView contains two views, each of them has an editor as visual representation, each editor edits a different FileObject. The first MultiView always displays fine, but when switching to the second a deadlock occurs. Thread dump will come...
Created attachment 30078 [details] Thread dump (2 days old CVS Head)
IMHO the multiview should not block the firing of settings changes: ... org.netbeans.core.multiview.MultiViewPeer.getEditorPane(MultiViewPeer.java:435) org.netbeans.core.multiview.MultiViewPeer.isToolbarVisible(MultiViewPeer.java:562) org.netbeans.core.multiview.MultiViewPeer$3.invoke(MultiViewPeer.java:547) $Proxy8.settingsChange(Unknown Source) org.netbeans.editor.Settings.fireSettingsChange(Settings.java:495) org.netbeans.editor.Settings.update(Settings.java:417) ... If possible the action should be performed asynchronously. Reassigning to core for further evaluation.
Passing to multiview author, I tend to agree with mmetelka, although blee to je hnus. What about that runtime class resolution and listener ugliness in multiview code to listen to editor settings...isn't friend API or so much better?
leonchiver, just a word of warning. The multiview won't work with multiple files in my opinion. to make them work we would have to rewrite the cloneableeditorsupport classes and change the the APIs in a non-compatible way. Firing an editor setting change asynchronously could help in this case.
done. the listener now invokeLaters the reaction to settings change. however please note that 1. I still believe 2 editors in multiview won't work. (that's calling for a complete rewrite of the editor support codebase/apis) 2. i'm not clear on how the changing of view could result in change in toolbar visibility settings..
*** Issue 80028 has been marked as a duplicate of this issue. ***
candidate for a fix in 5.5
Created attachment 32885 [details] change diff
Has this diff already been added to the trunk? I saw the same problem as of 08/24 NB daily build.
yes, it's been in trunk. (6.0, not 5.5)
joellelam: can you verify that your daily build was a 6.0, not a 5.5 one? I would like to merge the change to 5.5 branch but if it's not working, it'd rather not..
*** Issue 82619 has been marked as a duplicate of this issue. ***
mkleint: I was under ther impression that you were going to place it in the 5.5 build. Unfortunately this is a show stopper for us and will need it to be fixed. Are no longer planning to do this. By the way, I used the patch and it seems to work for me. I haven't ran into any problem yet. - Joelle
I reopen the bug since the fix should be merged in release55 branch.
blaha: have the rules for 5.5 integration changed? AFAIK the bug is fixed when in fixed in trunk and the 5.5_candidate tag is added. mail is sent to reviewers and when there's no objection, the fix is merged to 5.5 branch. Then the TM is set to 5.5 instead of dev..
Petr, Milos is right, this issue has already been fixed in trunk, just let the SW=5.5_candidate, we are tracking these issues ...
ok, since the patch is simple and was tested on 5.5, I merged it to 5.5
closed