Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » JFace » Ctrl+1 key binding lost in 3.3 to 3.6 upgrade.
Ctrl+1 key binding lost in 3.3 to 3.6 upgrade. [message #664178] Thu, 07 April 2011 18:04 Go to next message
Adil Fulara is currently offline Adil FularaFriend
Messages: 14
Registered: July 2009
Junior Member
Hello,

I recently upgraded my app from eclipse 3.3 to 3.6.1 platform. The transition has been smooth so far.

There is however a partial loss of functionality in one of text editors with quickassist. Although quickassist does work the way it is intended to.
The entry points for quickassist is either with key binding 'ctrl+1' or right click menu option 'quick fix'.
while the menu option does work as expected, the key binding does not seem to be picked up by the editor.

As per the eclipse docs, the text editor is configured by a subclass of TextSourceViewerConfiguration. For the api call getQuickAssistAssistant(), i return my implementation of IQuickAssistAssistant injected with an implementation of IQuickAssistProcessor.

Based on a blog post, http://eclipsesource.com/blogs/2009/07/08/tip-tracing-keybin dings-in-rcp/
i turned on tracing for the key binding and discovered that this key binding in not handled when invoked.

KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+1])
KEYS >>> WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.jdt.ui.edit.text.java.correction.assist.proposa ls', parameters = {})
KEYS >>> not handled

My understanding was that ctrl+1 is by default registered for quick-fix and should be picked up by the text editor or this was the case with the target platform 3.3

Any pointers as how i should go about wiring up this key binding in eclipse would be great. Is there something in the plugin.xml file that i need to add to inform eclipse that there is a processor wired up for ctrl+1 [ as it is able to do it correctly for the menu option selection]

Thank you,
Adil.

Report message to a moderator

Re: Ctrl+1 key binding lost in 3.3 to 3.6 upgrade. [message #664332 is a reply to message #664178] Fri, 08 April 2011 12:05 Go to previous messageGo to next message
Paul Webster is currently offline Paul WebsterFriend
Messages: 6859
Registered: July 2009
Location: Ottawa
Senior Member
On 04/07/2011 02:04 PM, Adil Fulara wrote:
> KEYS >>> WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+1])
> KEYS >>> WorkbenchKeyboard.executeCommand(commandId =
> 'org.eclipse.jdt.ui.edit.text.java.correction.assist.proposa ls',
> parameters = {})
> KEYS >>> not handled
>
> My understanding was that ctrl+1 is by default registered for quick-fix
> and should be picked up by the text editor or this was the case with the
> target platform 3.3

Where is the quick fix/ctrl+1 coming from?

I'll note that in 3.6 a "hole" was plugged. If the only "handler" for a
command was an objectContribution, that would not longer work
(objectContributions are only valid while a context menu is actually
shown, invalid for keybindings).

PW

--
Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Platform_Expression_Framework
http://wiki.eclipse.org/Menu_Contributions
http://wiki.eclipse.org/Menus_Extension_Mapping
http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse. platform.doc.isv/guide/workbench.htm

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Re: Ctrl+1 key binding lost in 3.3 to 3.6 upgrade. [message #664419 is a reply to message #664332] Fri, 08 April 2011 18:12 Go to previous messageGo to next message
Adil Fulara is currently offline Adil FularaFriend
Messages: 14
Registered: July 2009
Junior Member
Paul,

Thank you for your reply.

In v3.3, as per my understanding as long as we subclassed the

org.eclipse.ui.editors.text.TextEditor


class, key bindings were automatically dispatched from the workbench to my custom implementation of IQuickAssistAssistant + IQuickAssistProcessor.
So pressing 'ctrl+1' or 'ctrl+space' used to trigger my code. This does not seem to be happening on 3.6 as i see with the tracing option turned on.

This http://www.eclipse.org/forums/index.php?t=msg&goto=33460 0& forum entry is where i made the above assumption where Dani confirms that subclassing TextEditor basically hooks u up with ctrl+1. As mentioned in my previous post TextSourceViewerConfiguration subclass is where i provide the text editor with my QuickAssistAssitants. This is the reason why i dont have any bindings defined in my plugin.xml [extension point 'org.eclipse.ui.bindings'] as there is no command as such to invoke.

UPDATE:

Paul,
This is how i think my editor informs the workbench to make it quick fix aware [in reply to your q:Where is the quick fix/ctrl+1 coming from? ]

Action action = new ContentAssistAction(mResourceBundle, "ContentAssistProposal.", this);
String id = ITextEditorActionDefinitionIds.CONTENT_ASSIST_PROPOSALS;
action.setActionDefinitionId(id);
setAction("ContentAssistProposal", action);
markAsStateDependentAction("ContentAssistProposal", true);

getSourceViewer().getTextWidget().addVerifyKeyListener(new ParameterTraverseListener());
getSourceViewer().getTextWidget().addMouseListener(new ParameterMouseListener());

Sorry i am not an expert in the texteditor domain. So i may be stating the obvious

Thank you,
Adil.

[Updated on: Fri, 08 April 2011 22:55]

Report message to a moderator

Re: Ctrl+1 key binding lost in 3.3 to 3.6 upgrade. [message #667280 is a reply to message #664419] Wed, 27 April 2011 20:44 Go to previous messageGo to next message
Adil Fulara is currently offline Adil FularaFriend
Messages: 14
Registered: July 2009
Junior Member
I have had no luck resolving this issue.
Any help / pointers would be great.
Thank you.
Sad

Report message to a moderator

Re: Ctrl+1 key binding lost in 3.3 to 3.6 upgrade. [message #672112 is a reply to message #667280] Thu, 19 May 2011 22:54 Go to previous message
Adil Fulara is currently offline Adil FularaFriend
Messages: 14
Registered: July 2009
Junior Member
In case anyone is interested, i had to add key bindings "ctrl+1" and "ctrl+space" and map to unique commands.
Default handlers for these commands then need to get hold of your specific editor instance and use getAdapter() to get the target (instance of ITextOperationTarget) and ask the target if the method[canDoOperation()]is supported on ( ISourceViewer.CONTENTASSIST_PROPOSALS or ISourceViewer.QUICK_ASSIST ).

In my case, i had supplied quickassistants and processors so the api returns a true.

Then its just a matter of target.doOperation(SourceViewer.CONTENTASSIST_PROPOSALS or ISourceViewer.QUICK_ASSIST).

Thank you Paul for your assistance.

Report message to a moderator

Previous Topic:TableViewer/SWT Table: Bad performance with many columns
Next Topic:TableViewer change column amount depending on Input
Goto Forum:
  

[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Apr 18 06:55:59 GMT 2024

Powered by FUDForum. Page generated in 0.01921 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top

Sign up to our Newsletter

A fresh new issue delivered monthly