Sometimes you use the NetBeans API MultiViewElement class to create new tabs in a TopComponent, without needing to display a toolbar. However, as you can see below, you get an empty toolbar anyway, thanks to the getToolbarRepresentation override. That's a bit ugly...
...but gets even worse when the user tries to drag it, which sometimes succeeds, but then when they try to put it back, things might go wrong. Either way, this is the ugly error stack that they see:
Not very nice. My solution to this is simple, the same as described in this issue:
http://netbeans.org/bugzilla/show_bug.cgi?id=110008
I.e., rather than returning an empty JToolBar, return an empty JToolBar that has its floatable set to false:
@Override public JComponent getToolbarRepresentation() { JToolBar toolBar = new JToolBar(); toolBar.setFloatable(false); return toolBar; }
Then, not only can the toolbar not be dragged, which would be a reasonable solution, but it magically completely disappears, as can be seen below:
A perfect solution. And not only for empty JToolBars. Even if I had buttons in that JToolBar, setting the floatable to false fixes the same problem (see this for related code):
@Override public JComponent getToolbarRepresentation() { Action printAction = FileUtil.getConfigObject(" Actions/File/org-netbeans-modules-print-action-PrintAction.instance", Action.class); Action sysOpenAction = FileUtil.getConfigObject(" Actions/Edit/org-netbeans-core-ui-sysopen-SystemOpenAction.instance", Action.class); JToolBar toolBar = new JToolBar(); toolBar.setFloatable(false); JButton printButton = new JButton(printAction); printButton.setText(Actions.cutAmpersand((String)printAction.getValue(Action.NAME))); toolBar.add(printButton); toolBar.add(sysOpenAction); return toolBar; }
OK, then the toolbar can't be floated, but who cares, that's not something users expect to be able to do in this scenario.