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

Bug 332629

Summary:

When a user job runs a UIJob asynchronously MessageDialog#openConfirm closes and return true without user interaction

Product:

[Eclipse Project] Platform

Reporter:

Filipe Borges <fqborges>

Component:

Assignee:

Platform-UI-Inbox <Platform-UI-Inbox>

Status:

RESOLVED INVALID

QA Contact:

Severity:

normal

Priority:

CC:

remy.suen

Version:

4.1

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Code for simpleHandler containing the problem	none

Description Filipe Borges

2010-12-15 08:50:20 EST

Build Identifier: 3.5.1 M20090917-0800

when a user job (setUser(true)) running on top schedules a UIJob which promps the user using MessageDialog#openConfirm, that dialog closes and return true without user interaction.

Reproducible: Always

Steps to Reproduce:
1. Using PDE create a simple command/handler plugin
2. In handler#execute: schedule a job to do some work
3. In job.run: after doing the work, schedule a UIJob to prompt user
4. In uiJob.runInUIThread: prompts the user using MessageDialog#openConfirm
5. build your plugin and run as eclipse application
6. run the sample command from menu
7. the promp will show and hide very fastly without user interaction
8. MessageDialog#openConfirm will return 'true'

Comment 1 Filipe Borges

2010-12-15 08:52:04 EST

Created attachment 185224 [details]
Code for simpleHandler containing the problem

this is the code I used to reproduce the bug.

Comment 2 Remy Suen

2010-12-15 09:21:34 EST

This is because your message dialog is parented off of the progress dialog that's showing your first job. Hence, when it gets disposed, your message dialog also gets disposed (as it is a child shell of the progress dialog's shell).

You have two options here that I can think of.
1. Specify a small delay while scheduling your UI job. This will allow the dialog to be closed first before your UI job gets run. Then the active shell won't be the progress dialog of your first job.
2. Don't try to get the active shell from the display but instead be more specific about it (such as specifying the shell of the workbench window).

Comment 3 Oleg Besedin

2010-12-15 09:43:54 EST

(In reply to comment #2)
> 2. Don't try to get the active shell from the display but instead be more
> specific about it (such as specifying the shell of the workbench window).

+1, it would be nice if UIJob provided a bit more intelligent answer, but changing it now will surely break somebody else.

Comment 4 Filipe Borges

2010-12-15 10:09:42 EST

Thank you!

(In reply to comment #3)
> (In reply to comment #2)
> > 2. Don't try to get the active shell from the display but instead be more
> > specific about it (such as specifying the shell of the workbench window).
> 
> +1, it would be nice if UIJob provided a bit more intelligent answer, but
> changing it now will surely break somebody else.

One more question: how could I get the shell from workbench window without using internal UIPlugin?

Comment 5 Oleg Besedin

2010-12-15 10:36:45 EST

There are many ways, some might fit better your needs then others.

One possibility is to get Shell from your handler's event and pass it to the Job that will show up the dialog:

public class SampleHandler ... {
...

	public Object execute(ExecutionEvent event) throws ExecutionException {
	static Shell shell;
		IWorkbenchWindow window = HandlerUtil.getActiveWorkbenchWindowChecked(event);
		// TBD if (window != null); try/catch for ExecutionException 
		Shell shell = window.getShell();
		Job job = getJob(shell);
...
	}
	

====

Another possiblity is to use PlatformUI class:

	shell = PlatformUI.getWorkbench().getActiveWorkbenchWindow().getShell();

(this needs null checks and possibly #isWorkbenchRunning() check, if in doubt).