Community
Participate
Working Groups
From the class comment in WorkbenchAdvisor it looks like this should be used, but one of my test cases never receives the call. The test case I'm using has no windows, perhaps the intent is for #preShutdown to be used only when windows within the app are to be closed? At the very least, I think the comment should be updated.
Along the same lines, it looks like WorkbenchAdvisor.postRestore is never called either.
*** Bug 56564 has been marked as a duplicate of this bug. ***
preShutdown was just never getting called. We were considering simply removing it. However, having looked at what we do in busyClose, I think it would be beneficial to keep preShutdown after all, and allow it to veto the shutdown. There's a fair bit of work that gets done in busyClose, and the app may want to extend this to do more work, before the workbench windows are closed.
I've added the call to preShutdown, and removed postRestore. postRestore is not necessary since postStartup is probably close enough, and if not the app has control over when restore is done anyway (see WorkbenchAdvisor.openWindows). The RCP tests have been fixed up, and I've removed Andrew's '#ifdef's for this bug.
Ed, you should know about the changes here.
You got rid of postRestore() but not postWindowRestore() - shouldn't postWindowOpen() be close enough? In the current code there is a call to it but nobody overrides it that I can see. Shouldn't WorkbenchAdvisor.basicInitialize be called internalBasicInitialize or something like that to indicate it shouldn't be called? (besides the note in the Javadoc).
In comment #6 I meant "shouldn't postWindowCreate() be close enough" not postWindowOpen. I can't think of a use for postWindowRestore and removing it would be orthogonal to removing postRestore. BTW, I've made these updates in the RCP tutorials text but I'll hold off on redrawing the picture in case this other method is removed too.
The SDK implements postWindowRestore, to handle the switching of a restored window to a new perspective coming in on a newly-installed feature. See bug 21347 for the original request. This is a case where it needs to distinguish between a window that is being restored from a previous session, and one that is being newly created. A different way of doing this would be to pass a "restored" flag to postWindowCreate, but I don't see that as being tangibly better. I have no plans to change this for 3.0. I've renamed basicInitialize to internalBasicInitialize as you suggest. Note that it also protects itself from being called more than once.
