First, let me thank you for your wonderul framework. I’m facing some issues, I thought somebody could help me out, here’s the scenario.
I’m using dock_1.0.7 version. I’m working on a app whose docking skeleton is more like “paint” app, where there’s a explorer bar on the west, editor area at the center and some property windows on east. I’ve a JMenu item (“New Editor” with accelerator set to Ctr + N) that creates a new editor dockable in the center, which is a CDockable added to CWorkingArea (like Paint). Here is the problem:
When I try to use Eclipse Theme, and select “New Editor” menu option using mouse then a new dockable window is added to the center working area as expected. But when I use the key accelerator Ctrl+N (keyboard shortcut) and it throws out the following error. The samething doesn’t happen with BasicTheme! For testing purpose, I’ve slightly modified the paint app to reproduce this error, and shown below, where I’ve removed the prompting for picture name instead returning some auto generated message and modified ViewManager, Core and PictureRepositoryDockable appropriately to access the New Editor functionality. Please note that this problem can be simulate only when you remove the prompt window asking for new pic. name.
I’ve also attached my code, run it and press Ctrl+N to get the error.
Exception in thread "AWT-EventQueue-0" java.lang.IndexOutOfBoundsException: Index: 2, Size: 2
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at bibliothek.extension.gui.dock.theme.eclipse.EclipseStackDockComponent.getDockable(EclipseStackDockComponent.java:208)
at bibliothek.extension.gui.dock.theme.eclipse.EclipseFocusTraversalPolicy.list(EclipseFocusTraversalPolicy.java:57)
at bibliothek.extension.gui.dock.theme.eclipse.EclipseFocusTraversalPolicy.getAfter(EclipseFocusTraversalPolicy.java:76)
at bibliothek.gui.dock.focus.DockFocusTraversalPolicy.getComponentAfter(DockFocusTraversalPolicy.java:86)
at bibliothek.gui.dock.focus.DockFocusTraversalPolicy.after(DockFocusTraversalPolicy.java:144)
at bibliothek.gui.dock.focus.DockFocusTraversalPolicy.after(DockFocusTraversalPolicy.java:157)
at bibliothek.gui.dock.focus.DockFocusTraversalPolicy.getComponentAfter(DockFocusTraversalPolicy.java:92)
at javax.swing.SortingFocusTraversalPolicy.getComponentAfter(SortingFocusTraversalPolicy.java:230)
at javax.swing.LayoutFocusTraversalPolicy.getComponentAfter(LayoutFocusTraversalPolicy.java:88)
at java.awt.Component.preNextFocusHelper(Component.java:7637)
at java.awt.Component.nextFocusHelper(Component.java:7616)
at java.awt.Container.nextFocusHelper(Container.java:3154)
at java.awt.Component.doAutoTransfer(Component.java:7548)
at java.awt.Component.autoTransferFocus(Component.java:7540)
at java.awt.Component.autoTransferFocus(Component.java:7515)
at java.awt.Component.hide(Component.java:1596)
at java.awt.Component.show(Component.java:1565)
at java.awt.Component.setVisible(Component.java:1515)
at javax.swing.JComponent.setVisible(JComponent.java:2612)
at java.awt.CardLayout.show(CardLayout.java:522)
at bibliothek.extension.gui.dock.theme.eclipse.rex.RexTabbedComponent.setSelectedTab(RexTabbedComponent.java:454)
at bibliothek.extension.gui.dock.theme.eclipse.rex.RexTabbedComponent.insertTab(RexTabbedComponent.java:264)
at bibliothek.extension.gui.dock.theme.eclipse.EclipseStackDockComponent.insertTab(EclipseStackDockComponent.java:202)
at bibliothek.gui.dock.StackDockStation.add(StackDockStation.java:765)
at bibliothek.gui.dock.StackDockStation.drop(StackDockStation.java:484)
at bibliothek.gui.dock.SplitDockStation.drop(SplitDockStation.java:1234)
at bibliothek.gui.dock.SplitDockStation.drop(SplitDockStation.java:1121)
at bibliothek.gui.dock.SplitDockStation.drop(SplitDockStation.java:1105)
at bibliothek.gui.dock.facile.state.StateManager.drop(StateManager.java:1109)
at bibliothek.gui.dock.facile.state.StateManager.normalize(StateManager.java:968)
at bibliothek.gui.dock.facile.state.StateManager.change(StateManager.java:793)
at bibliothek.gui.dock.facile.state.StateManager.change(StateManager.java:771)
at bibliothek.gui.dock.facile.state.StateManager.transition(StateManager.java:694)
at bibliothek.gui.dock.common.intern.CStateManager.setLocation(CStateManager.java:472)
at bibliothek.gui.dock.common.CControl$Access.show(CControl.java:2071)
at bibliothek.gui.dock.common.intern.AbstractCDockable.setVisible(AbstractCDockable.java:204)
at bibliothek.paint.view.ViewManager.open(ViewManager.java:159)
at bibliothek.paint.view.ViewManager$1.pictureAdded(ViewManager.java:101)
at bibliothek.paint.model.PictureRepository.add(PictureRepository.java:124)
at bibliothek.paint.view.PictureRepositoryDockable.newPicture(PictureRepositoryDockable.java:198)
at bibliothek.paint.view.ViewManager.newPicture(ViewManager.java:134)
at bibliothek.paint.Core$1.actionPerformed(Core.java:119)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:1995)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractBut .......
In the attached code, where I’ve the following areas:
West : Explorer Area (SingleCDockable)
Center: Editor area (MultipleCDockable added ot CWorkingArea)
Bottom: Output Area (SingleCDockable)
East: Split into to parts: Top for Overview area (SingleCDockable), bottom for Status (SingleCDockable)
In the above app, after I minimize both EAST side windows(dockables): Overview and Status, and when I normalize the Overview window, it’s not going back to its old position instead going to north/center! How can I make sure that it can restore back to its position?
When I add multiple editors (pictures) where the # of windows is more than that can fit in the title bar size, then the EclipseTheme doesn’t seem to wrap the tabs, unlike BasicTheme. Instead, the tabs are shrunk! May be that’s how the theme is designed, but is there anyway to wrap it?
I had similar problems with the eclipse theme (doing different stuff but the same exception).
It was related to an incompatibility with certain jre versions.
Which java are you using?
I looked at your thread, but this problem doesn’t seem to be specific to a JRE, since I tried both with 1.5.0_11 as well as 1.6.0_16. You can run the attached java program to simulate it, once you open just press Ctrl+N to reproduce that error. This doesn’t happen when you mouse-select the File-> New (after you relaunch the program).
Do you’ve any thoughts on the other 2 issues? Thanks.
I’m currently at work, I’ll write a longer reply later.
I through I had corrected this in 1.0.7, it certainly does no longer happen in 1.0.8 (I’ll test your code).
Not in 1.0.7. In 1.0.8 a menu will be added if there is not enough space for the tabs.
Question: any chance of using the preview versions of 1.0.8? They are as stable as any other version, and I really don’t want to start fixing things in 1.0.7 that are already fixed in 1.0.8.
In 1.0.7 it works depending on the FocusManager that is used by the JRE. The FocusManager seems to be modified in every second release… In 1.0.8 your example does not always work, but that is because there are no Components on the Dockable and my FocusManager enters an infinite loop. If there were Components on the Dockables, then it would work.
Again: these problems are resolved in 1.0.8 (more or less), and if possible you should use one of the preview versions. If that is not possible for you I can at least fix bug 1 (but not 2 or 3).
I did spend some thoughts on issue 2, at least your example should now have another behavior (already in 1.0.8p3).
I did add a unique identifier to each leaf and node in the tree that represents a SplitDockStation. If a Dockable is now added with a specific path, first these ids are checked: if one id in the path matches the id of a leaf or node in the station, then the path is added at that location. This wont work with paths and layouts that have been stored in an earlier version.
I’ve tried the above program on 1.0.8p3 where I minimized east side both dockables (east top and east bottom) and restored one after another, yeah the behavior is different but still they couldn’t remember their old positions.
As an attempt, I’ve slightly modified the above program to reposition on Minimize and Normalize by registering these 2 actions. And it’s still not able to restore to the old positions. see the attached program.
Is there any specific way to remember their positions programmatically?
What exactly do you mean with “specific way to remember their positions”? You can always ask a CDockable for its current location (using ‘getBaseLocation()’).
I meant to reposition them when they’re normalized based on their earlier positions programmatically.
It gets complicated when other dockables are minimized or normalized in between the current dockable’s minimize and normalize period. I’m already trying to position as part of my normalize action to their desired positions, but the framework doesn’t seem to calculate their positions right.
One sequence of events that does not work. Assuming two Dockable A and B that are neighbours and normalized: 1. Minimize A, 2. Minimize B, 3. Normalize A, 4. Normlize B… and now they are stacked.
In step 3 some information is thrown away because the tree is smaller, but this information would be needed to set B at its correct position.
Eclipse can handle this case :twisted:
I’ll try the following: I not only store the path, but I also store the whole tree. That should provide enough information to do some real work. Results available next week…
Is there any specific way to remember their positions programmatically?
After reading your example code, there is not much more to do. If you try to use a path (=a location, in this case) that does not really fit in the current tree, the framework starts to guess. You can try and create a good path before giving it to the framework, if you succeed please send me a copy of your code.
(Actually a call to „setLocation“ is enough, you don’t need to call „super.action(dockable)“ any more in your new actions)
After some trial and error I decided to add placeholders in the tree of a SplitDockStation: if a dockable is removed from the station its placeholder remains (the tree does not shrink) and the dockable can later be inserted at its old location (which was never deleted).
Since this screams “resource leak” this mechanism will only be available for those dockables that are somehow registered at a CControl. Clients can override the default behavior with the property-key SplitDockStation.PLACEHOLDER_STRATEGY and allow any dockable to be remembered.
I’m still testing and implementing the remaining parts, so this change won’t be available for the next few days.
The system works already for SplitDockStation and for some of the other stations as well. I still have to test persistent storage and implement secure removal of invalid placeholders. I’ll finish this work maybe this weekend (unlikely) or next week.
