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

Bug 250169

Summary:

Problems with extending the menu's of results in Remote Search View

Product:

[Tools] Target Management

Reporter:

Kevin Doyle <kjdoyle>

Component:

RSE

Assignee:

David McKnight <dmcknigh>

Status:

RESOLVED FIXED

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

normal

Priority:

CC:

kjdoyle, rdibugs

Version:

3.0.1

Target Milestone:

3.1 M3

Hardware:

OS:

Windows XP

Whiteboard:

Bug Depends on:

Bug Blocks:

256286

Attachments:

Description	Flags
patch to use dummy selection provider until the real provider is avaible	none

Description Kevin Doyle

2008-10-08 16:09:15 EDT

Using the org.eclipse.menu's extension point to extend the results of the Remote Search View is not possible as it's not registering it's menu.

If in SystemSearchViewPart.addSearchResult(IAdaptable) I add the following line after line 425:

getSite().registerContextMenu(menuMgr, currentViewer);

I can now add menu's to the view.  However when I try to get the selection from my action (ex. SystemDynamicUserActionMenu) it gets a NPE.

window.getSelectionService().getSelection();  is returning null.

Comment 1 David McKnight

2008-11-20 15:50:18 EST

Created attachment 118400 [details]
patch to use dummy selection provider until the real provider is avaible

The problem is that when the search view part is first created, there is no view (just an empty shell).  When the part is activated, Eclipse retrieves the site's selection provider but, at this point, the search view does not have a search going on, so it doesn't have a viewer nor a selection provider.  Even if the selection provider is set after that (i.e. when addSearchResult()) is called and a viewer is created), because the selection service (i.e. AbstractSelectionService) does not reset the active part, we're left in a state where the provider is null.  In order to avoid that problem this patch creates a dummy selection provider that defers to the actual provider if one exists.  Once AbstractSelectionService.setActivePart() gets called again later on, the actual select provider should get picked up. 

I'm not sure whether this is the best solution.  If there is a clean way to get a call to AbstractSelectionService.setActivePart() after we do the getSite().setSelectionProvider() then it might be preferable.

Could you try this out and see if the patch helps?

Comment 2 David McKnight

2008-11-21 16:17:13 EST

I've committed the code to cvs.

Comment 3 Kevin Doyle

2008-11-23 22:33:51 EST

Patch works.  Thanks Dave.  Can we backport?

Comment 4 David McKnight

2008-11-24 10:04:43 EST

(In reply to comment #3)
> Patch works.  Thanks Dave.  Can we backport?
> 

Kevin, I think for this to work in 3.0.2 we need a backport for bug 242431.  Is
that something you're planning?

Comment 5 Kevin Doyle

2008-11-28 11:21:58 EST

(In reply to comment #4)
> Kevin, I think for this to work in 3.0.2 we need a backport for bug 242431.  Is
> that something you're planning?
> 

As we discussed this works for me without the need to backport bug 242431.