| Summary: | [Coolbar] [RCP] ICoolBarManager#setLockLayout called in ActionBarAdvisor#fillCoolBar | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Sebastian Davids <sdavids> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | n.a.edgar, psuzzi |
| Version: | 3.1 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
The locked state is restored during start-up as part of the
WorkbenchWindow.restoreState code. It is restored, as it is controllable in the
Eclipse SDK via a LockToolBarAction.
Out of curiousity, if you delete the following file before running your RCP
application, does it still appear in the incorrect state?
<rcp_app_workspace>/.metadata/.plugins/org.eclipse.ui.workbench/workbench.xml
(Alternatively, you can just delete the "coolbarLayout" element and all of its
subelements ... in this same file.)
Nick: can you comment on how the "restoreState" should appear (chronologically
speaking) with respect to the "fillCoolBar" and "postWindowOpen" methods?
If I run a clean RCP app, i.e. the configuration data does not exist yet, it does not work. The use case would be: An RCP app with no LockToolBarAction but locked toolbars. Not the configuration data, but the workspace data. In this case as well? fillActionBars is called quite early, while the WorkbenchWindow is still in its constructor. The window's state is restored after. The coolbar's lock state is one of the attributes the workbench owns, so it saves and restores that state. If the coolbar was locked the first time the window was opened, it should be saved and restored that way. The problem is that CoolBarManager.setLockLayout only works if the CoolBar already exists. It does not mirror that state. During fillActionBars, the controls haven't yet been created. The workaround is to look the coolbars during postWindowCreate, which will also override any saved state. >>In this case as well?
Yupp.
Heh. The restore state code *always* set the locked state, even if there is no persisted value. It defaults to "false", and hence your problems. Moving Dougs bugs This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
If I have the code below, I'd expect the coolbar to be locked when the application is opened: MyActionBarAdvisor#fillCoolBar(ICoolBarManager coolBar) { coolBar.add(exampleAction); coolBar.setLockLayout(true); } Unfortunately this is not the case. Doing MyWorkbenchWindowAdvisor#postWindowOpen() { IActionBarConfigurer configurer = getWindowConfigurer() .getActionBarConfigurer(); ICoolBarManager coolBarManager = configurer.getCoolBarManager(); coolBarManager.setLockLayout(true); } will do the trick. @@@@ I'm not sure if this is a bug or by design :)