Community
Participate
Working Groups
Use I20061219-0800 or newer to reproduce but problem also in earlier builds. I added code to restore the editor selection upon restart (see bug 124615). This works for all (also if >1 window) but the first restored editor: the selection is not correctly revealed and the the scroll bar thumbs aren't correct. There are two reasons that cause this: one is SWT bug 168429 and the other one is this one: When the very first editor is restored partActived(...) and if using IPartListener2 also partVisible(...) are called before the part's widgets are actually visible i.e. editor's StyledText.isVisble() returns false. This is not expected. Clicking on other editor tabs afterwards shows the correct behavior. See also bug 154112 which might be related but not that this bug only appears for the very first visible editor and works when activating other not yet realized editors.
Another problem that this bug causes is described in bug 170877. We need to find a fix for this for 3.3.
This code hasn't changed (which means this problem has always been there). The partVisible() on startup I've tracked down to: LayoutPart#getVisible() - "This returns whatever was last passed into setVisible, but does not necessarily indicate that the part can be seen" The activation is a "model" activation event, so it also won't gaurantee the controls are really visible and have been layed out during the startup case. Dani, is this a problem that's been highlighted in new code that you've added, or is this in existing code? I'm wondering if this behaviour has now been highlighted since we're spinning the event loop during workbench/workbench window initial startup and restore. asyncExec(*) might allow the events to be deferred until after startup ... but our new splash story might not allow that. We'll need some investigation (changing any of the workbench event ordering is risky :-) PW
>Dani, is this a problem that's been highlighted in new code that you've added, >or is this in existing code? Yes, this is the new code that restores the caret location.
>We'll need some investigation (changing any of the workbench event ordering is >risky :-) Not, if you have enough test cases.
This looks like legacy behaviour (so I don't think we need to delay M5). I run the XMLEditor example from 3.2.2 and added an IPartListener2 in the init(*) method. On a restart we've always had a part active and part visible event before the control has been layed out: partActivated: false partActivated: Point {0, 0} partVisible: false partActivated: Point {0, 0} As opposed to a normal activation: partVisible: true partActivated: Point {528, 431} partActivated: true partActivated: Point {528, 431} PW
>This looks like legacy behaviour That's well possible. >(so I don't think we need to delay M5). No, of course not. I thought I was clear about that in my note. Even if we'd find a fix, comment 2 already mentioned that it is fragile to touch the event story.
(In reply to comment #6) > No, of course not. I thought I was clear about that in my note. Yes, we were on the same page :-) Platform UI was investigating the possiblity because we were worried that if we broke text (admittedly new code) that we might break some of the other projects that hope to demo behaviour on M5. But we are less worried now. PW
*** Bug 170877 has been marked as a duplicate of this bug. ***
*** Bug 177057 has been marked as a duplicate of this bug. ***
An interesting side-effect of this bug: http://inside-swt.blogspot.com/2007/03/useless-dialog-of-day.html
*** Bug 178741 has been marked as a duplicate of this bug. ***
Created attachment 64551 [details] Investigation patch v01 Can partActivated/partVisible be delayed if the control is not visible? It looks like an asyncExec(*) will delay the firing until later. PW
Created attachment 64598 [details] Investigation patch v02 Slightly cleaner version of the patch. PW
Delaying the activate/visible events approach changes the event ordering during startup. Parts events are interleaved (which may or may not be a bad thing) and sometimes a partHidden can come before a partVisible (which is not good). A better approach would be to enhance the deferUpdates(*) protocol to fire the events at the end of startup. This would have to be threaded through the part lists, activation lists, and perspectives. Deferring until 3.4. PW
Created attachment 94906 [details] Part Service approach v01 This is an investigation patch. When a page or window is created, start up in defer updates mode ... queue up all part events. When the window is opened or the page is realized, then fire the events. UC-1 open a session and restore the window UC-2 open a second window UC-3 open a page after closing all perspectives. This investigation only includes UC1 so far. PW
Created attachment 95536 [details] Part Service approach v02 A slightly better approach for maintaining event order within the window and page, the window has one deferred event queue that the pages use as well. UC-4 Instantiate the Javadoc view after the window is up. partVisible(*) is fired before it has been layed out. PW
Created attachment 95571 [details] Part Service v03 Different take on the part service approach. Wait to fire the events for visible, active, and brought to top until the part pane control is visible and has been laid out at least once. Far and away the most accurate (but also the scariest). PW
Created attachment 95743 [details] Part Service v04 Use SWT events to determine when it's applicable to fire partVisible, partActivated, and partBroughtToTop. PW
Released to HEAD >20080411 PW
In I20080429-0100 PW
