Community
Participate
Working Groups
build I20021119 Several people have requested the ability to avoid updating a view when it is hidden, then bringing it up to date when made visible. At the SWT level, there is no callback to notify when a control has become hidden or visible (other than the paint callback). Control.isVisible() only tells you whether the control and all its parents have been set to be visible, not whether it is obscured. However, at the Workbench level, we know when a view is visible. We know: - whether it is a regular view, not in a tab folder, - whether it is frontmost in a tab folder - whether it is the active fast view - whether it is obscured by a zoomed view or editor We should investigate adding an IPartListener2 interface with partHidden and partVisible methods. Below is a representatitve request for this feature, from boxall@ca.ibm.com: I would like to raise this topic again because we still need to have a solution for debug engines that have many local variables, (in the thousands) Since making the last append I added code that watches for the closing of the variables view. This allows me to tell the connected debug engine to stop monitoring locals when the user closes the variable view. This doesn't really solve the problem. What I really want is notification when the variables view is hidden so that I have the opportunity to disable/suppress local variable monitoring until the variables view becomes visiable again. I can't use the "IPartListener.partDeactivated()" message because just the act of giving another view focus (not hiding the variables view) will create this event. The user still expects the variables view to update as long as it is visible.
This should be considered as part of the performance improvement work for 2.1 M4.
Note that you can currently track part visibility using the following hack. If you hook a resize listener on the view's control, its size will go to 0@0 when hidden. This relies on internal implementation details which may change in the future, but it may let those interested do some prototyping. If you do this, not that the resize callback is currently being sent multiple times when the part is made visible. Filed bug 27086 for this. This means that you'll need to be careful to only update on the first resize when going from hidden to visible (you would need to do this anyway to properly handle arbitrary resizes).
I just want to make sure that this change actually notifies listeners when the view goes hidden (user can't see it) and not just stops asking for content. The view hidden notification will allow me to tell a debug engine to stop monitoring. The way I interact with engines requires that I tell the engine to stop or start monitoring locals. Getting a hidden notification would allow me to tell the engine to stop monitoring. The next time the view requests content I would tell the engine to start monitoring and return the results to the view.
Yes, that is how it should work. It sounds like you're referring to getContents method that content providers implement when using JFace Viewers. Note that the proposal here is independent of whether you use JFace Viewers or not. We'll simply notify your View (not the same thing as a Viewer) when it is hidden and or made visible. If you're using JFace Viewers, then you would stop updating the viewer when the view is hidden, and would probably issue a full refresh to the viewer when the view is made visible.
Sounds like what I want. Thx
Added IPartListener2 and released to the HEAD. We are using setVisible instead of setBounds(0,0,0,0) so the workaround proposed in the Comment #2 will not work anymore.
