Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 93766

Summary: [Coolbar] [RCP] ICoolBarManager#setLockLayout called in ActionBarAdvisor#fillCoolBar
Product: [Eclipse Project] Platform Reporter: Sebastian Davids <sdavids>
Component: UIAssignee: 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

Description Sebastian Davids CLA 2005-05-05 00:26:54 EDT
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 :)
Comment 1 Douglas Pollock CLA 2005-05-05 11:32:52 EDT
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?
Comment 2 Sebastian Davids CLA 2005-05-05 12:51:57 EDT
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.
Comment 3 Douglas Pollock CLA 2005-05-05 13:07:18 EDT
Not the configuration data, but the workspace data.  In this case as well?
Comment 4 Nick Edgar CLA 2005-05-05 13:27:46 EDT
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.
Comment 5 Sebastian Davids CLA 2005-05-05 13:49:12 EDT
>>In this case as well?
Yupp.
Comment 6 Douglas Pollock CLA 2005-05-05 16:34:50 EDT
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.

Comment 7 Michael Van Meekeren CLA 2006-04-21 13:23:23 EDT
Moving Dougs bugs
Comment 8 Eclipse Genie CLA 2020-02-15 20:28:44 EST
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.