My problem now is that I want to attach the CDockable(s) in ContentArea 2 back to ContentArea 1. Since I was not able to get a list of the dockables directly from the ContentArea object, I tried to add a CDockableStateListener to the CDockable, but none of the methods were called by the control.removeContentArea() call or the closing of the JFrame itself
That seems to be a bug in the framework. You should receive an event on “CDockableStateListener.visibilityChanged”.
There was a bug related to the remove-method in version 1.0.8 preventing the method from doing anything. What version are you using? If it is 1.0.8, upgrade to 1.1.0 (1.1.0 is almost finished, the current “preview” version is as good as a stable version).
I’m currently at work, but once I’m at home I’ll check the listeners and write again if (or if not) I find a bug.
Your assumption is correct, I am currently using 1.0.8 and will switch to 1.1.0 as you suggested.
In the class CControl I found the following JavaDoc for the method remove(CContentArea):
Elements aboard the stations are made invisible, but not removed from this control.
So as you have written, the JavaDoc indicates that CDockableStateListener.visibilityChanged would be called, but in the method remove(CStation) which is called by removeContentArea() the JavaDoc states that the behaviour would be unspecified:
Removes a CStation from this control. It is unspecified what happens with the children on station
The method visibilityChanged() is called for each dockable in the removed ContentArea when the line “dockable.setVisible(true);” is not there, but if it is there it is called twice for the first CDockable (because I change the visibility), but not at all for the other dockables in the ContentArea.
The change of the visibility within this method seem in some way to reset the call stack.
dockable.addCDockableStateListener(new CDockableAdapter() {
@Override
public void visibilityChanged(CDockable dockable) {
if (!dockable.isVisible()) {
dockable.setLocation(CLocation.base(contentArea).normal());
dockable.setVisible(true);
}
}
});
Another problem I encountered with 1.1.0 together with the corresponding Glass Preview is that it seems to always paint the title icon, even if I call setTitleIcon(null).
If I set control.putProperty(EclipseTheme.PAINT_ICONS_WHEN_DESELECTED, false), the icons fo deselected tabs are not painted, but for all other dockables they are still painted.
[QUOTE=Karsten]Switched to 1.1.0, but got a funny result …
The method visibilityChanged() is called for each dockable in the removed ContentArea when the line „dockable.setVisible(true);“ is not there, but if it is there it is called twice for the first CDockable (because I change the visibility), but not at all for the other dockables in the ContentArea.
The change of the visibility within this method seem in some way to reset the call stack.
dockable.addCDockableStateListener(new CDockableAdapter() {
@Override
public void visibilityChanged(CDockable dockable) {
if (!dockable.isVisible()) {
dockable.setLocation(CLocation.base(contentArea).normal());
dockable.setVisible(true);
}
}
});
[/quote]
What happens is this: the framework recursively visits Dockables and DockStations in order to fire the events. But because you move a Dockable to a new position, the data structure changes while the framework is still visiting.
I’ll add some code to make the framework resistent against this error. But in the meantime you can workaround the bug by calling „EventQueue.invokeLater“ with a Runnable that calls the „setVisible“ method.
Currently null is replaced by the default icon, but I’ll change the behavior. In the next version null stays null.
The reason behind having a default icon is, that sometimes there is a button representing a Dockable, and this button does not look very good without icon.
If I set control.putProperty(EclipseTheme.PAINT_ICONS_WHEN_DESELECTED, false), the icons fo deselected tabs are not painted, but for all other dockables they are still painted.
That is the intended behavior. The property only affects stacks of Dockables.
I’m currently finishing some other features and bugfixes, but I’ll upload a new version within this week.
Not with the current version. But you could set an invisible Icon with size 0/0.
I’m currently rewriting the entire mechanism that handles icons, that is the main reason why options are limited.
