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.
May 18 refactoring build (if it matters). JDK 1.5.0b51. Selected a form file - I18nPanel.java in fact - and Tools -> Internationalization submenu items are all disabled. multiview problem?
This actually works for me in today dev build (200405231800). However - by fixing issue 43575 (related to issue 43683) this appears again. The problem now is that NodeAction gets 2 nodes as activated (in fact one node twice) - I guess this happens due to setting the node as activated once on the java editor TopComponent and then immediately on the multiview TopComponent. While this makes TopComponent.Registry to fire activated nodes properly (and so Toggle Breakpoint action works), it somehow duplicates the change in the actions lookup (so I18n action does not work). Any idea what could be done with this?
i guess I will have to filter out the duplicate items in the lookup. for this case a simple == check should be enough, however in general it could be hard to achieve a really consistent lookup with MVElements that are topcomponents.
ok, seems to be more complicated than anticipated. The default lookup in topcomponent will get activated node, add it to lookup and expand all it's lookup item to the tc's lookup as well. No idea why, but all these items will now appear twice in the MultiViewTC's lookup. (in case the currently selected Element is a TopComponent by chance)
Milos - the algorithm you mention is Yarda's. Impl in DefaultTopComponentLookup I think.
yup. the problem is however that I got 2 instances of DefaultTopComponentLookup that I need to merge.. maybe with another one? However I don't understand the code well enough, plus it's not public so I'd rather not copy the code over to multiview module.
This is a piece of functionality that must work correctly. There is a TopComponentGetLookupTest that cointains all the painful experience I had to go thru when fixing bugs reported against the lookup<->nodes interaction. The same code has already been copied to implement ExplorerUtils.createLookup (ExplorerManager) so copying it once more does not form any big obsticle, if.. You should create MultiViewGetLookupTest in your module and extend the TopComponentGetLookupTest and override the creational methods (exactly as done in ExplorerManager...Test). That way we can ensure that your implementation is correct (behaves the same). Moreover whenever somebody fixes a bug it should add new test into TopComponentGetLookupTest and we will immediatelly be notified about failure in all other places.
I've managed to make the test working from multiviews for the usecase where nodes are activated on the inner element and checks are done against the outer (multiview) component lookup. However the I18N actions atill don't work. :) I've figured the problem is that the i18n.wizards.Util class checks for EditorCookie on the nodes, however the FormNode instances don't have it. that change in util class was done by pkuzel in version 1.5. before this change at least the I18NWizardAction.java (in version 1.11) didn't check for editor cookie in the activated nodes.
commited the changes in multiview to trunk. for the remaining problems with i18n actions, reassigning to i18n.
Fixed also the remaining problems. /cvs/i18n/src/org/netbeans/modules/i18n/I18nAction.java new revision: 1.17; previous revision: 1.16 /cvs/i18n/src/org/netbeans/modules/i18n/wizard/Util.java new revision: 1.11; previous revision: 1.10