Bug 319250

Comment 1 Thomas Schindl 2010-07-08 06:35:07 EDT

It looks like there are 2 problems:
a) The handler code was wrong => it was not storing the shell appropriately
   => Fixed in HEAD
b) A problem with keybindings not restored, when coming back from the shell:
   To reproduce this:
  -1. Set a break point in ...liveeditor.OpenLiveDialogHandler#run()
   0. Select something in the Package Explorer
   1. Hit ALT+SHIFT+F9
   2. Close shell
   3. Hit ALT+SHIFT+F9 (run not invoked) => none of the keybindings work
   4. Change the active part e.g. selecting something in the editor area
   5. Hit ALT+SHIFT+F9 (run invoked)

Comment 2 Thomas Schindl 2010-07-08 06:58:06 EDT

I think I found the problem with the keybindings. When the shell is opened the part e.g. the Package Explorer is deactivated (=no part is active), when closing the shell and clicking inside the Package Explorer for example doesn't reactivate it but the Workbench still believes that there's NO active part.

Once you e.g. click into the Editor or some other part of the system an active part is dedected and keybinding start to work again. This problem doesn't seem to happen with Dialogs e.g. CTRL/CMD+N which somehow manage to set back the active part when closed.

Is there some magic going on there?

Comment 3 Remy Suen 2010-07-08 07:20:12 EDT

Oleg was going trying some changes in the WBWRenderer for reactivation of parts though that might only apply to the activation of different workbench windows.

Comment 4 Remy Suen 2010-07-08 09:45:42 EDT

(In reply to comment #2)
> Is there some magic going on there?

For reasons that are not clear to me, when the live dialog is closed, a SWT.Deactivate event is not sent.

Comment 5 Thomas Schindl 2010-07-09 05:49:58 EDT

2 things:
a) I'm not spinning the event loop after having opened
b) I'm SWT.ON_TOP

I'll try spinning the event loop may that's the cause of the problem. I think dialogs, ... are spinning event loop on open()

Comment 6 Thomas Schindl 2010-07-09 05:55:36 EDT

Nope none of this help :-(

Comment 7 Thomas Schindl 2010-07-09 06:27:36 EDT

Ok. I found the reasonn why it works e.g. for dialogs but not for my shell. The reason is that when using
-------8<-------
new Shell(s.getDisplay(),SWT.SHELL_TRIM);
-------8<-------
You *DON'T* get a Deactivation-Event when the shell closes.

Whereas you get one if you open a shell like this:
-------8<-------
new Shell(s,SWT.SHELL_TRIM);
-------8<-------

Probably some SWT-Experts can explain to us why. For us this means listening to SWT.Deactivate is probably not enough because we can't force the user to create a shell as the parent of another one.

Comment 8 Thomas Schindl 2010-07-09 06:28:41 EDT

Just to clarify "s" is the current active-shell:

	@Execute
	public void run(@Named(IServiceConstants.ACTIVE_SHELL) Shell s,
			IEclipseContext c, MApplication application, IStylingEngine engine) {
// ....
}

Comment 9 Thomas Schindl 2010-07-09 06:30:54 EDT

Released my Shell-Creation change to HEAD => For me the bug is fixed but we should probably open a new defect to discuss how we can fix this SWT.Deactivation issue in the workbench code