I have set addCDockableStateListener for a DefaultMultipleCDockable and whenever the dock is placed in the CWorkingArea or the user clicks the “X” of the tab, the visibilityChanged method fires.
Questions:
(1) What in the CDockable passed into visibilityChanged, what method or field is set to determine if the dock is being put into or being removed from the CWorkingArea?
(2) How can I retrieve the DefaultMultipleCDockable from the CDockable passed into visibilityChanged?
(3) Once I have the DefaultMultipleCDockable from the CDockable, how do I extract the JComponent that was originally set in it? There could be 1 of 3 JComponents in the DefaultMultipleCDockable, so I have an “if” with “instanceof” to determine which JComponent is being removed so other cleanup can be done.
My application is very dynamic and generally has at least 1 other thread running for each JComponent being displayed. i.e. 1 feeder thread per dock constantly updating the display. So, I have a lot of work that needs to be done when the user clicks the “X” on the tab.
1: well, isVisible tells you whether the dockable currently has a parent or not (is visible or not). getParentStation tells you what the parent is.
2: only by casting
3: CDockable.intern().getComponent()
I would suggest to write a subclass of DefaultMultipleCDockable and have your listener defined as inner class. Then you don’t need to cast, and you have access to all the inner fields of your specialized dockable. Maybe even one subclass for each type of Component you would like to show - then you may get rid of “ifs” and “instanceofs”, which are almost always a big source of bugs.
Apon further research and playing around in the debugger, I noticed the isShow() method of visibilityChanged is true when the dock is displayed in the CWorkingArea and false when it is being removed. Can I safely assume that this will always work that way, so that I can know the difference between being displayed and being destroyed (deleted).
You are asking “how does x work” questions, when you should ask “how is use-case y supported”. You are like one of these users that tell me “on line 38 your application has a bug” instead of “click on button z and something strange happens”. Meaning: you don’t provide enough information to give you any helpful answer.
I can only guess what you are trying to achieve, and give you an answer that helps you finding the information you need yourself.
A working-area is nothing special, it’s just a flag. It’s just an element that helps grouping Dockables, but even if a Dockable is linked to a working-area it could still be showing up somewhere else (e.g. being minimized or floating on its own dialog). “Visibility” tells you whether the Dockable is visible (on a working-area or somewhere else), and the “CDockableStateListener” tells you whether visibility changed. A working-area does not know which Dockables are linked to it, only the Dockables know their working-area. During drag and drop operations the class “WorkingAreaAcceptance” does prevent the user from dropping the Dockable anywhere but inside its working-area.
The framework itself will never change “visibility” on its own, visbility can only go to “false” if either the user closes some Dockable, or if the application closes the Dockable. If a Dockable is completely removed, then CControlListener#removed is called (incidentally CControlListener can also be used to globally monitor the visibility flag of all CDockables). If it is not removed, then the “removed”-method is not called.
“showing” tells you whether the user can actually see the element right now (think of JComponent#isShowing), it can be monitored with the CDockableLocationListener.
As per my comments in the other posting, you should update the Common Overview PDF and the CWorkingArea JavaDocs per your comments above and the parentage or lack of parentage for CWorkingArea.