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.

Bug 16587 - Problems with adding/removing views dynamically
Summary: Problems with adding/removing views dynamically
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 3.x
Hardware: Sun SunOS
: P2 blocker (vote)
Assignee: Jan Jancura
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-16 01:08 UTC by Torbjorn Norbye
Modified: 2002-01-14 14:44 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Torbjorn Norbye 2001-10-16 01:08:11 UTC
Let me first cover the simple case.

I've implemented "docking" and "undocking" actions for the debugging
window. I can now undock a view from the debugging window, and it shows
up in a separate NetBeans container; I can then dock it back into
the debugging window.  (A small problem here is that when it is docked
back the view is not made visible, and my code to make it visible does
not work - see bug 16584 for that issue).

This works fine as long as I undock and redock a window that was originally
in the debugging window.  But I have 4 debugging views which are originally
docked in the Output window.  When I try to dock these into the debugging
window, it does not work.  (I basically do topcomponent.close(), followed
by looking up its View2Support object, which I then do a
  guimanager.addView(viewsupport)
with.)       I checked and the view2support's getComponent() method is
called (and I return the right object), but nothing is drawn in the
debugging window. An area -is- reserved for the component, but it's all
gray - nothing is painted in it.  When I call "isShowing()" in my topcomponent
it returns false, so it looks like the component has not been added. 

Now the more general problem (and the reason this is a P2).
I actually need to change the full set of views in the debugger window
on the fly.

Here's the scenario. Currently, I set all the debuggerviews in the GUI manager
at startup to be -my- debuggerviews.  But if somebody wants to run the
JPDA debugger they're hosed - now my views are showing in the JPDAdebugger
instead of yorus, and the JPDA debugger is unusable.    I was hoping to
work around this by NOT setting my debuggerviews at startup and instead
doing it as part of Debugger.startDebugger().  But that didn't work (I
suspect it's the same bug as above, on a more general scale - adding views
after the debugging workspace is showing doesn't seem to work).

I think it would be best if there was some code which allowed each debugger
to set the current contents of the debugger window such that all the views
could be updated. That way a user could switch between the two debuggers
(JPDA, mine) and the views could update as needed.  That won't work now
since the JPDA debugger doesn't know that it needs to set the views back
after I've changed them, but at least by fixing this bug my debugger can
allow its users a choice between the two, and you can run both, just not
simultaneously.
Comment 1 Torbjorn Norbye 2001-11-15 00:32:26 UTC
Part 1 below (the part about the area being left gray) is a duplicate
of http://www.netbeans.org/issues/show_bug.cgi?id=17691 which I
just filed with a proposed fix; if you apply that patch that portion
of this bug is fixed.

However, there is still a problem with changing the views dynamically:
when I start with a clean user directory and start up my debugger,
which replaces all the debugger views, none of them are made visible
(none of them are selected in the toolbar, even though isSelected
is true for the View objects). I'll see if I can come up with an
isolated testcase for this on the train tomorrow morning.
Comment 2 Jan Jancura 2001-11-15 19:51:58 UTC
I can not reproduce this bug (Part 2). I have tested this
functionality and it works for me. 
Do you use View2Support?
Do you return true in View2.isVisible ()? NOT isSelected () !!!
Can you create some testcase, please?

My test:
I have removed out registration of some views in my DebuggerModule and
add them to JPDADebuggerModule. And it works.
Comment 3 Torbjorn Norbye 2001-11-17 20:44:55 UTC
It's not 100% reproducible. For some reason, it seems to happen
often on Solaris x86, but hardly ever on SPARC. So it may be
some race condition. (I've also sometimes seen the debugging
window come up on the wrong workspace (the editing workspace) before
switching to the Debugging workspace.)

I'll try to investigate this more closely on Monday and come up
with a testcase.
Comment 4 Jan Chalupa 2001-11-27 12:10:25 UTC
Target milestone -> 3.3.1.
Comment 5 Torbjorn Norbye 2001-11-28 07:26:22 UTC
I can reproduce it on SPARC as well, and it even happens when I register
my views at startup. It only happens when I start with a clean user
directory.
On subsequent starts the right selection state is persisted.

I've inserted a bunch of System.out.println's in debuggercore's
ToolbarView.

Here's what I came up with:

I added a trace message to ToolbarView's "isVisible()",
"setVisible(View, boolean)" and
"setVisible(HashSet)" methods.

First I see this:

ToolbarView.isVisible Sessions from viewsupport: false
ToolbarView.isVisible Threads from viewsupport: false
ToolbarView.isVisible Stack from viewsupport: true
ToolbarView.isVisible Local Variables from viewsupport: true
ToolbarView.isVisible Watches from viewsupport: true
ToolbarView.isVisible Expressions from viewsupport: true
ToolbarView.isVisible Breakpoints from viewsupport: false

Note - three views are visible, and these are the Krakatoa debugger
views. The
"from viewsupport" portion is telling me that it read the visibility from
the ViewSupport object's isVisible() method, not from the "visible" array
stored in ToolbarView.


Next I see this:

ToolbarView.setVisible([View2Support
org.netbeans.modules.debugger.support.nodes.BreakpointsView,
View2Support org.netbeans.modules.debugger.support.nodes.ToolbarView,
View2Support
org.netbeans.modules.debugger.support.nodes.FilterToolbar,
View2Support
org.netbeans.modules.debugger.support.nodes.CallStackView,
View2Support
org.netbeans.modules.debugger.support.nodes.PropertiesView,
View2Support org.netbeans.modules.debugger.support.nodes.WatchesView])

That's setting the views to the JPDA debugger views!

And next I see this:

ToolbarView.isVisible Sessions from visible array: false
ToolbarView.isVisible Threads from visible array: false
ToolbarView.isVisible Stack from visible array: false
... etc.

Now the views are returning -false- for visible - Stack's visibility was
true earlier. But now it's telling me that it read the visibility from
the "visible" array, which of course contains JPDA debugger views now.

So the big mystery is why the JPDA debugger views are showing up in the
middle of this.

Here's the stacktrace from that setVisible call:


ToolbarView.setVisible([View2Support
org.netbeans.modules.debugger.support.nodes.BreakpointsView,
View2Support org.netbeans.modules.debugger.support.nodes.ToolbarView,
View2Support
org.netbeans.modules.debugger.support.nodes.FilterToolbar,
View2Support
org.netbeans.modules.debugger.support.nodes.CallStackView,
View2Support
org.netbeans.modules.debugger.support.nodes.PropertiesView,
View2Support org.netbeans.modules.debugger.support.nodes.WatchesView])
java.lang.Exception: Stack trace
  at java.lang.Thread.dumpStack(Thread.java:993)
  at
org.netbeans.modules.debugger.support.nodes.ToolbarView.setVisible(ToolbarView.java:167)
  at
org.netbeans.modules.debugger.support.nodes.DebuggerWindow.initSpecialViews(DebuggerWindow.java:621)
  at
org.netbeans.modules.debugger.support.nodes.DebuggerWindow.showViews(DebuggerWindow.java:433)
  at
org.netbeans.modules.debugger.support.nodes.DebuggerWindow.setViews(DebuggerWindow.java:351)
  at
org.netbeans.modules.debugger.support.nodes.DebuggerWindow.addNotify(DebuggerWindow.java:192)
  at java.awt.Container.addImpl(Container.java:374)
  at java.awt.Container.add(Container.java:228)
  at
org.netbeans.core.windows.frames.MultiTabbedContainerImpl.attachComponents(MultiTabbedContainerImpl.java:197)
  at
org.netbeans.core.windows.frames.DefaultContainerImpl.setAttached(DefaultContainerImpl.java:497)
  at org.netbeans.core.windows.ModeImpl.setVisible(ModeImpl.java:1152)
  at
org.netbeans.core.windows.ModeImpl$1.performCommand(ModeImpl.java:394)
  at
org.netbeans.core.windows.DeferredPerformer.processCommand(DeferredPerformer.java:165)
  at
org.netbeans.core.windows.DeferredPerformer.putRequest(DeferredPerformer.java:83)
  at org.netbeans.core.windows.ModeImpl.dockInto(ModeImpl.java:367)
  at org.netbeans.core.windows.ModeImpl.dockInto(ModeImpl.java:347)
  at org.netbeans.core.windows.ModeImpl.dockInto(ModeImpl.java:335)
  at
org.netbeans.core.windows.WindowManagerImpl$TopComponentManager.doOpen(WindowManagerImpl.java:1425)
  at
org.netbeans.core.windows.WindowManagerImpl$TopComponentManager.open(WindowManagerImpl.java:1382)
  at org.openide.windows.TopComponent.open(TopComponent.java:220)
  at
org.netbeans.core.windows.layers.TCRefImpl.performCommand(TCRefImpl.java:160)
  at
org.netbeans.core.windows.DeferredPerformer.processCommand(DeferredPerformer.java:165)
  at
org.netbeans.core.windows.DeferredPerformer.putRequest(DeferredPerformer.java:83)
  at
org.netbeans.core.windows.layers.TCRefImpl.updateMode(TCRefImpl.java:202)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.addComponents(ModeData.java:749)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.updateComponents(ModeData.java:626)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.loadDataSection(ModeData.java:1057)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.updateProperties(ModeData.java:490)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.updateAll(ModeData.java:402)
  at
org.netbeans.core.windows.layers.ModeData$CookiesImpl.createInstance(ModeData.java:334)
  at
org.netbeans.core.windows.layers.ICFolderImpl$R.run(ICFolderImpl.java:259)
  at
org.netbeans.core.windows.layers.ICFolderImpl.instanceCreate(ICFolderImpl.java:121)
  at
org.netbeans.core.windows.layers.WorkspaceData$InstanceCookieImpl.createModes(WorkspaceData.java:483)
  at
org.netbeans.core.windows.layers.WorkspaceData$InstanceCookieImpl.updateModes(WorkspaceData.java:420)
  at
org.netbeans.core.windows.layers.WorkspaceData$InstanceCookieImpl.updateAll(WorkspaceData.java:358)
  at
org.netbeans.core.windows.layers.WorkspaceData$InstanceCookieImpl.loadDataSection(WorkspaceData.java:673)
  at
org.netbeans.core.windows.WorkspaceImpl.ensureSectionLoaded(WorkspaceImpl.java:894)
  at
org.netbeans.core.windows.WorkspaceImpl.setVisible(WorkspaceImpl.java:623)
  at
org.netbeans.core.windows.WindowManagerImpl.setCurrentWorkspace(WindowManagerImpl.java:421)
  at
org.netbeans.core.windows.WorkspaceImpl.activate(WorkspaceImpl.java:406)
  at
org.netbeans.modules.debugger.support.DebuggerModule.changeWorkspace(DebuggerModule.java:343)
  at
com.sun.forte.developer.ipe.debugger.actions.LoadProgramAction.performAction(LoadProgramAction.java:197)
  at
org.openide.util.actions.NodeAction.actionPerformed(NodeAction.java:169)
  at
com.sun.forte.developer.ipe.debugger.actions.DebugStartAction$MainItemListener.actionPerformed(DebugStartAction.java:242)
  at
javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1450)
  at
javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(AbstractButton.java:1504)
  at
javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:378)
  at
javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:250)
  at javax.swing.AbstractButton.doClick(AbstractButton.java:279)
  at
javax.swing.plaf.basic.BasicMenuItemUI$MouseInputHandler.mouseReleased(BasicMenuItemUI.java:886)
  at java.awt.Component.processMouseEvent(Component.java:3730)
  at java.awt.Component.processEvent(Component.java:3559)
  at java.awt.Container.processEvent(Container.java:1164)
  at javax.swing.JComponent.processEvent(JComponent.java:4390)
  at java.awt.Component.dispatchEventImpl(Component.java:2608)
  at java.awt.Container.dispatchEventImpl(Container.java:1213)
  at java.awt.Component.dispatchEvent(Component.java:2512)
  at
java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:2451)
  at java.awt.LightweightDispatcher.processMouseEvent(Container.java:2216)
  at java.awt.LightweightDispatcher.dispatchEvent(Container.java:2125)
  at java.awt.Container.dispatchEventImpl(Container.java:1200)
  at java.awt.Window.dispatchEventImpl(Window.java:932)
  at java.awt.Component.dispatchEvent(Component.java:2512)
  at java.awt.EventQueue.dispatchEvent(EventQueue.java:339)
  at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:131)
  at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:98)
  at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
  at java.awt.EventDispatchThread.run(EventDispatchThread.java:85)

It looks like this is during window workspace deserialization.
Perhaps that code needs to consider the case where alternate GUI
views have been registered?

Alternatively, perhaps I need to re-register my views at some point
during debugger startup?
Comment 6 Jan Jancura 2002-01-10 15:53:32 UTC
Should be fixed now. Try our testcase
(http://debuggercore.netbeans.org/source/browse/debuggercore/api/examples/delegatingview/),
please.
Can you create some testcase and reopen it, if the bug still occurres,
please?
Thanks for report