Bugzilla – Full Text Bug Listing
| Summary: | [Commands] [GTK] Handler activation in editor when a dialog is closed is delayed | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jean-Michel Lemieux <jean-michel_lemieux> |
| Component: | UI | Assignee: | Paul Webster <pwebster> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.3 | ||
| Target Milestone: | 3.4 M6 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 173213 | ||
| Bug Blocks: | |||
JM, bug 173213 is investigation a fix for this condition (running a workbench window command from a dialog). If accepted, the fix basically involves registering the dialog shell to allow the active workbench window to continue to work. ex: dialog.create(); getContextService().registerShell(dialog.getShell(), IContextService.TYPE_DIALOG_SUPPORTS_WORKBENCH); // Check result of dialog if (dialog.open() == Window.OK) { Then the command would work without the need to resort to a UI job. PW This ended up being a complex problem. In 3.3 we're experimenting with using a snapshot of the context to execute a command. If this solution proves out, in 3.4 we'll work on making this API PW As per bug 183810 there is now API available to execute a command in a different context (where being in a dialog is definitely a different context). ex: IEvaluationContext windowContext = handlerService.createContextSnapshot(true); MyDialog d = ...; d.setContext(windowContext); d.open(); In MyDialog when executing, create the appropriate ParameterizedCommand and: handlerService.executeCommandInContext(pCommand, null, windowContext); PW fixed by bug 183810 In I20080325-0100 |
Here is a test case which fails on Linux: Setup: This code is run within an editor. When the editor is created, it registers a command handler. Within the widget selected event, a dialog is shown and when closed the command is invoked but the command handler isn't found. But delaying the command invocation until some time has passed will succeed because the command handler has been reset since the shell disposed event has had time to be processed. autoMergeButton.addSelectionListener(new SelectionAdapter() { @Override public void widgetSelected(SelectionEvent e) { IPreferenceStore store = UiPlugin.getDefault().getPreferenceStore(); boolean prompt = true; //MessageDialogWithToggle.PROMPT.equals(store.getString(UiPlugin.AUTO_MERGE_CONTENT_PROMPT)); if(prompt) { MessageDialogWithToggle dialog = MessageDialogWithToggle.openOkCancelConfirm(autoMergeButton.getShell(), "Auto-merge", "This will merge all non-conflicting changes in this file. It's possible that the file type being " + "merged doesn't support this kind of operation, in which case you'll have to merge the file manually. Also, if the " + "file has already been merged, this action will not change the file. After the auto-merge the file still " + "needs to be saved. \n\n" + "Do you want to continue?", "Do not ask again", false, store, UiPlugin.AUTO_MERGE_CONTENT_PROMPT); if(dialog.getReturnCode() != IDialogConstants.OK_ID) return; } UIJob job = new UIJob(shell.getDisplay(), "Merging") { @Override public IStatus runInUIThread(IProgressMonitor monitor) { mergeRightToLeft(parent.getShell()); return Status.OK_STATUS; } }; job.schedule(150); } });