my application consists of several SingleCDockables. I have recently enhanced the application by placing some new functionality into a new/further SingleCDockable. The new dockable is not part of former persisted layouts. So when loading these layouts, the new dockable gets a null parent station and is invisible.
Goal:
Under such circumstances, I would like to put the new / “orphaned” dockable to minimalNorth and visible.
Problem:
I have not been unable to programatically set a default location (CLocation.base.minimalNorth()) and setVisible. I’ve also tried in vain to assign some CContentArea station as parent.
In any these cases, after all calls to the dockable, isVisibile still returns false.
There is no mechanism implemented to let things like this happen automatically.
Im not certain when you call these methods. You need to make all these calls, setLocation, setVisible, after you load a layout. Because loading a layout will always override any other settings.
Another solution could be to access the perspective API (CControl.getPerspectives), then load the different perspectives and insert the Dockable. You would need to do this the first time the application starts with the new items, afterwards the layouts stay modified. This would be my preferred solution, as you can do this before your application really starts. The code could would look somewhat like this:
Both calls are issued after loading the layout. Where could I look to if isVisibile remains false afterwards?
My situation is as follows:
[ul]
[li]Initial layout (incl. that new dockable) is done using a CGrid[/li][LIST]
[li]If no layout load occurs I’m fine with this[/li][/ul]
[li]There are a lot of existing layout files (written by writeXML) that do not contain the dockable[/li][/LIST]
Is it still possible to init the layout using the CGrid (instead of the perspective)?
How would load/save layout interact with get/set perspectives? (eg., does layout load leave unknown parts of the perspective un-modified?)
Both calls are issued after loading the layout. Where could I look to if isVisibile remains false afterwards?
Could you post the code doing that? Calling setVisible(true) does not offer much options for failure. So I’m not certain we speak of the same thing, or maybe you found a bug I missed.
Layout information appears in different shapes: as xml file, as binary file, as Components on the screen. To convert one format to another, there is an „intermediate format“, to which clients do not have direct access. If you store a layout, it gets converted into the „intermediate format“ and remains in that format until it gets loaded again - or until the application shuts down.
The perspective API only adds a new way to access the intermediate format.
Perspectives and layouts are different views on the same data. And hence any modification of a layout has an effect on its perspective, and any modification of a perspective affects the layout. There are no parts that are unknown by one view only, either something is stored in the intermediate format - and then both layout and perspective know of it - or it isn’t.
Does that make things more understandable?
In an application you normally have a flow like this:
calling main
calling new CControl
maybe set up initial layout
use „readXML“ to read stored layouts
With the perspective API you add:
5. modify intermediate format with perspective API
6. call „CControl.load“ to reload the current, now modified, layout
You would have the same effects if you would:
open the xml file with a text editor
manually write the data for the new dockable at the correct place
[QUOTE=Beni]Could you post the code doing that? Calling setVisible(true) does not offer much options for failure. So I’m not certain we speak of the same thing, or maybe you found a bug I missed.
[/QUOTE]
I don’t have the code fragment on the computer I’m currently working on.
But, as I now understand much better the concept of perspectives, I will try to achieve my aim based on your second proposal (which was also your preferred one).
Now I understand that I have to separate step 4 and 6 and work on the perspective in between.
How would I assess which dockable is missing in the intermediate format?
I think this information would be needed in order to ensure that the dockable’s layout is only changed if it was not part of the layout file.
The best solution would be to find out, whether the new application is loading resources from an older version. Then, and only then, the new dockables should be added to the perspectives.
If you do it every time, the user will not be able to close a Dockable properly. Because you always reset the “visibility” property.
But if you are already at the point where you want to find a Dockable in the perspectives:
CPerspective offers a method “elements”, which returns an Iterator over all "PerspectiveElement"s (an iterator over all CElementPerspectives is currently missing).
If a “PerspectiveElement” is an instance of “CommonElementPerspective” you can call “getElement” to gain access to a “CElementPerspective”.
The “CElementPerspective” may be an instanceof of “SingleCDockablePerspective”.
If you find a “SingleCDockablePerspective” you know the SingleCDockable with the same id will be in the layout.
If you don’t find a “SingleCDockablePerspective” for some id, then this dockable will be missing in the layout.