I am currently using the 1.1.0p4 release (Eclipse Theme with and without GlassExtension) and I am facing a serious problem with missing SingleCDockables after dragging them. This happens
When I drag a title bar into the “body” of the dockable. No black border for target area is shown during the dragging.
When I drag a dockable left out of the window and sometimes also when I drag it below the window. The dockable gets lost even if I set setExternalizable(false). The lost dockable can be temporary recovered when I externalize another dockable from the same ContentArea using the standard button, after this both dockables are shown as a stack. But as soon as I attach one of them back to the ContentArea, the other one gets hidden.
I have added to screenshots for case 1. In both screenshots, I started with pressing the left mouse button on the “Log” tab. In “TargetAreaDrawn”, I have dragged the mouse pointer up and right and the dockable also appears in this location as expected. In “TargetAreaNotDrawn”, I have dragged the mouse cursor down and right (about where the miniature window appears) and if I release the mouse, the dockable completely disappears.
This bug may be related to this one. Unfortunately until now I was not able to reproduce neither your not the other bug.
Next time a Dockable goes missing, could you please execute the following piece of code? It would be interesting to know if the missing Dockable still has a parent station and what that station is.
What strikes me very odd is the fact that there seem to be two “Root” elements with different identifier. At the beginning “Log” is a child of “Root [id=1296314383337]”, afterwards it is a child of “Root [id=1296314384576]”.
This means that there are two different SplitDockStations (this is not necessarily a bad thing). In your case the second SplitDockStation seems to be invisible, and thus elements on it disappear.
Question: do you create more than one CContentArea, CWorkingArea and/or CGridArea? Could there be an invisible JFrame hidden behind the visible one?
[Edit: ah, I first have to check your test. We just wrote concurrently…]
The framework has the implicit assumption that all root-stations are visible.
However, I was upgrading the visibility stuff for a feature request that is floating around in the forum, so with the next release (tomorrow) there is a method that can accurately tell whether a Dockable or DockStation is visible to the user or not.
Then you can add this piece of code to your application and the example will be fixed:
public boolean accept( DockStation parent, Dockable child, Dockable next ){
return isVisible( parent );
}
@Override
public boolean accept( DockStation parent, Dockable dockable ){
return isVisible( parent );
}
public boolean isVisible( DockStation parent ){
return parent.isStationVisible();
}
});```
A "DockAcceptance" can tell the framework not to allow some Dockable on some DockStation, and "isStationVisible" tells whether some DockStation is visible to the user. In the current version "visible" is equivalent to "Component.isDisplayable", but in the next release it will be "Component.isShowing" which much better fits.
We have a slight problem after implementing this listener. I have attached an example. Before adding this listener, the 2nd frame showed two dockables (yellow and blue). After adding this listener, only the yellow one is shown.
There is a bit a question: what is more important, the rule you set or the location you set? Because the rule clearly tells that the Dockable should not be a child of any station which is not visible (and neither station is visible). In any case its either both Dockables should be on the second frame or none at all.
I’ll update the internal mechanism a bit, going in the direction of “the rule is more important”. In the next release the second frame will be empty, and all the Dockables will be forced upon the default-station: the rule cannot be satisfied but at least the Dockables are shown.
Perhaps you want to make the call of “setLocation” and “setVisible” override the rule. In this case I would temporarily disable the rule while applying your changes. You could just override “setLocation” and “setVisible” and set some boolean which is recognized by the rule (setLocation is never called by the framework, setVisible may be called).
I think my post was a little bit misleading. We currently have no problem (since the DockAcceptance seems not to be necessary any longer), so no code change of any type is requested or required by us.
I am just wondering why the first dockable appears in that setup but not the second? But that is solely curiosity
I am afraid that the latest version (7a) is a large step back in our environment. The way we set the locations of dockables seems to work no longer.
You can verify this by running the example posted above. Basically, everything is added to the main ContentArea despite setting the location with “dockable3.setLocation(CLocation.base(contentArea2).normal());”
You are not the first complaining. Yesterday I fixed a bug, unfortunately that caused another one. I’ll repair the new bug this evening, the API should afterwards work again as expected. Please stick with the old version for a while
Just a bug that needed fixing (well, a very minor bug).