Eclipse: Perform an action any time an editor receives input - eclipse

I'm wondering if it is possible to determine what input was just entered inside of an editor in Eclipse - I'm currently working off of the example JDT editor - and then perform an action based on that input.
e.g.: I have a file example.jav open in my editor window. I push the 'a' key. 'a' would appear in the editor window per normal, but 'a' would also print out to the console.
Obviously the operation I'll be performing will be more complicated than a System.out.println() statement, but if someone could help show me where the change gets detected by the editor itself, I can take it from there.
A few notes:
I'm working in Eclipse 3.7.2 with Java 1.7
If you cannot find the JDT example editor, go to Help > Welcome > Samples and click on "Java Editor".
Thanks in advance!

Figured it out!
As the Editor API is so vast in eclipse that it is difficult to know where to start, I focused on adding a KeyListener to my Shell. Turns out that is slightly problematic in SWT, as when an item inside the Shell gains focus, the Shell itself looses focus. After a bit of searching though, I stumbled across someone else who had the same problem. By adding a filter to the Shell's display, you can add a Listener object which works for the entire application. Such as:
IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
Shell shell = window.getShell();
shell.getDisplay().addFilter(SWT.KeyDown, new Listener()
{
public void handleEvent(Event event)
{
System.out.println("" + event.character);
}
});
To further this and only worry about keys pressed in a specific non-widget part (otherwise you could just add a KeyListener to that part) you can add a check to make sure that the currently active part is the same as whatever part you wish to perform the actions for by using a simple if check.
final IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow();
Shell shell = window.getShell();
shell.getDisplay().addFilter(SWT.KeyDown, new Listener()
{
public void handleEvent(Event event)
{
IWorkbenchPage page = window.getActivePage();
IWorkbenchPart part = page.getActivePart();
IEditorPart editor = page.getActiveEditor();
if(part.equals(editor))
{
System.out.println("" + event.character);
}
}
});
Here is hoping that this helps someone else have an easier time than I had finding the solution!

Related

SWT FileDialog Browse Location

I have a simple file dialog in my RCP application which lets the users to select a file as per the code snippet below
Label filePathLabel = new Label(composite, SWT.NULL);
filePathLabel.setText("File Path");
Text filePathText = new Text(composite, SWT.BORDER);
filePathText.setText("");
Button browseButton = new Button(composite, SWT.PUSH);
FileDialog fileDialog = new FileDialog(getShell(), SWT.SAVE);
fileDialog.setFilterExtensions(new String[] {"*.txt"});
fileDialog.setFilterNames(new String[] {"Textfiles(*.txt)"});
browseButton.addSelectionListener(new SelectionAdapter()
{
#override
public void widgetSelected(final SelectionEvent e)
{
String path = fileDialog.open();
if(path != null && !path.isEmpty())
{
filePathText.setText(path);
}
}
});
The problem I'm facing is that I have not been able to get the previous browse location of the file after I close my RCP application and start it again since all the controls (Text, FileDialog) will be recreated. I save the result of fileDialog.open which returns the path and set the filePathText Text control's setText(Text text) method whenever my WizardPage is reopened to show the previous browse location selected but I loose access to the browse location after I close my RCP application so the next time I reopen my application I have not been able to set the filePathText text to the previously browsed location even though Eclipse does point to the previously browsed location after I click the browse button but I need to know the previously browsed location even before I click browse button so that it can be displayed in the Text control.
I found some suggestions on this site - https://dzone.com/articles/remember-state but I don't think it would help me in remembering the state of the browse location with respect to FileDialog
Please correct me if I'm missing something here.
You use the IDialogSettings mentioned in the link to save and restore information for a wizard. Wizards provide some methods to help.
In the constructor of your main Wizard class set the dialog settings the Wizard should use. This might be:
public MyWizard()
{
setDialogSettings(Activator.getDefault().getDialogSettings());
}
where Activator is the activator for your plug-in (this only works if the activator extends AbstractUIPlugin).
Once you have done this your WizardPage can access the settings:
IDialogSettings settings = getDialogSettings()
When the File Dialog returns the location you can save that in the settings:
settings.put("path", path);
When you are creating the file path Text you can check if you have a saved value:
String savedPath = settings.get("path");
if (savedPath != null) {
filePathText.setText(savedPath);
}

Unable to type once the Content Assist shell is popped up

I have attached a content assist to a text box by using the below code. The content assist is working fine.
But, once I press the 'Ctrl+space', then, All the proposals are displayed in a newly created shell.
Then, I try to type some more characters, but, I'm unable to type, as the new shell has the focus, not the text box.
Is there a way to minic, how the JDT editor does? Even after pressing the Ctrl+space and content proposals are displayed, we are able to type in the editor and the proposals are narrowed down based on the new characters.
private void attachContentAssist(final Text propertyText) {
ContentProposalAdapter contentProposalAdapter = new ContentProposalAdapter(propertyText, new TextContentAdapter(),
this.proposalProvider, KeyStroke.getInstance("Ctrl+Space"), null);
contentProposalAdapter.setLabelProvider(new ContentProposalLabelProvider());
contentProposalAdapter.setPropagateKeys(false);
contentProposalAdapter.setProposalAcceptanceStyle(ContentProposalAdapter.PROPOSAL_REPLACE);
}
The line:
contentProposalAdapter.setPropagateKeys(false);
is stopping keys received while to pop-up is open being forwarded to the Text control, this is what is stopping the typing working.
Either specify true or remove the line as true is the default.

e4 dynamic menu contributions

This feature has been realized as of Kepler M4, for a detailed information on the usage see my blog
I want to realize a fully dynamic menu contribution to the menu of a handler located in a view toolbar. In Eclipse 3 it was possible to add "dynamic" as org.eclipse.ui.menus contribution to a Menu!
I already found out about www.vogella.com/blog/2010/10/26/processors-e4-model explaining on how to dynamically contribute to menus by means of processor model extensions but I am talking about a completely dynamic menu implementation which changes on every call of the resp. submenu. As mentioned this was no problem to realize in Eclipse 3.x via the dynamic menu contribution and the set of isDynamic() to true.
I already tried several approaches:
Registering a processor hooking to a menu => no dynamic add possible (new elements are simply not shown, also discussed in Eclipse Forum - Cannot replace menu items at runtime)
Listening to the UIEventTopic for the event of creating the menu, getting the widget for Modification => modifications to the swt.Menu gathered are simply ignored (every listener, element etc.) (for info RCP Event Model
Open, untried solutions
Inserting a ToolControl to try an SWT approach -> quite complicated but may work
I've been banging my head for some time now, but can't seem to understand the correct implementation of this problem within E4.
-- This question was also asked in Eclipse Forum - Dynamic menu contributions
----- UPDATE
I tried a different approach up to now:
I added a HandledToolItem to the Menu (please see the following image)
and with the following code I am trying to interfere with the menus way to build, where the code is called by the resp. command handleer as referenced in the image.
#CanExecute
public boolean canExecute(#Optional MApplication application) {
System.out.println("CanExecute Counter="+counter);
// --- 1 ---
// Find the required MMenu Entry in the Application Model
if(application == null) return true;
EModelService modelService = (EModelService) application.getContext().get(EModelService.class.getName());
MPart part = (MPart) modelService.find("at.medevit.emr.contacts.ui.contactselector", application);
List<MToolBarElement> lmte = part.getToolbar().getChildren();
HandledToolItemImpl htil = null;
for (MToolBarElement mToolBarElement : lmte) {
if(mToolBarElement.getElementId().equals("at.medevit.emr.contacts.ui.contactselector.toolbar.handledtoolitem.filter")) htil = (HandledToolItemImpl) mToolBarElement;
}
if(htil != null) {
MMenu elemMenu = htil.getMenu();
// --- 2 ---
// Found it hopefully, let's start the real work, simply add a new item
MDirectMenuItem mdi = MMenuFactory.INSTANCE.createDirectMenuItem();
mdi.setLabel("Counter "+counter);
counter++;
// --- 3 ---
elemMenu.getChildren().add(mdi); // ConcurrentModificationException
}
As one can see, this code is queried once the menu is created, to determine whether the command is executable or not. All the code from 1 - 2 is to find the correct MMenu element to work on. The code from 2 - 3 creates a MenuItem and increments a counter in the field.
BUT at 3 I face a java.util.ConcurrentModificationException the first time the menu is opened! I assume that at this very point the menu is iterating over elemMenu.getChildren() and I am not allowed to enable!
So whats all the fuzz about the entire e4 model being changeable all the time ;) (just kiddin' I know this is a baaaad hack!!!)
Thing is: I really think that the possibility to add fully dynamic menu parts is one of the best usability tools, and if it is not possible to realize it in E4 as it was in E3 this is a very serious degradation of possibilities!!!
-- UPDATE
An Eclipse Bug has been filed for this https://bugs.eclipse.org/bugs/show_bug.cgi?id=389063
Proper dynamic model updates should be handled in the bug you've opened. As a workaround in Eclipse4 in Juno, a MRenderedMenuItem can be created in Eclipse4 to provide the equivalent functionality to the dynamic element (although if you are using 4.2, you would just use org.eclipse.ui.menus).
ex:
ContextFunction generator = new ContextFunction() {
#Override
public Object compute(IEclipseContext context) {
return new MyCompoundContributionItem(context);
}
};
MRenderedMenuItem menuItem = MenuFactoryImpl.eINSTANCE.createRenderedMenuItem();
menuItem.setElementId(id);
menuItem.setContributionItem(generator);
container.getChildren().add(menuItem);
This effectively provides a CompoundContributionItem directly to the Eclipse4 menu renderer.

SWT/JFace Minimize/Maximize EditorArea

I didn't manage to find any functionalities for minimizing/maximizing programatically.
I want to minimize my editorArea when all the editors are closed.
Any suggestions?
Thanks in advance.
I found a workaround to minimize the editorArea. It's not very nice but it's doing the job.
WorkbenchPage page = (WorkbenchPage)PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage();
IEditorReference[] editorReferences = page.getEditorReferences();
if(editorReferences.length==0){
page.getActivePerspective().setEditorAreaState(IStackPresentationSite.STATE_MINIMIZED);
}
I really don't like that cast but I cant get the concrete class.
Any suggestions for improving this?
You can show/hide editor area using IWorkbenchPage.setEditorAreaVisible(). You could do this by adding IPerspectiveListener to the window.
public void perspectiveChanged(IWorkbenchPage page,
IPerspectiveDescriptor perspective, String changeId) {
if (changeId == IWorkbenchPage.CHANGE_EDITOR_CLOSE) {
if (page.isEditorAreaVisible() && page.getEditorReferences().length == 0)
page.setEditorAreaVisible(false);
}
}
While it is also possible to minimize editor area using setPartState() method of the page, this can't be done after all editors are closed. Even though the last editor reference is available in close editor event handler, the reference to ILayoutContainer has already been removed and thus can't be used to change the state.
I found this bug on bugs.eclipse.com: https://bugs.eclipse.org/bugs/show_bug.cgi?id=29840 but i can't find the ZoomManagement.

How to redirect key presses to another shell in an Eclipse-based app?

I'm working on a way to maximise an EditorPart in my Eclipse-based RCP app to be absolutely full-screen, no trim, no menu, and so on. Actually, it's a GEF Editor. It's a bit of a hack, but it kind of works:
GraphicalViewer viewer = (GraphicalViewer)getWorkbenchPart().getAdapter(GraphicalViewer.class);
Control control = viewer.getControl();
Composite oldParent = control.getParent();
Shell shell = new Shell(SWT.APPLICATION_MODAL);
shell.setFullScreen(true);
shell.setMaximized(true);
// Some code here to listen to Esc key to dispose Shell and return...
shell.setLayout(new FillLayout());
control.setParent(shell);
shell.open();
Basically it sets the parent of the GraphicalViewer control to the newly created, maximised Shell. Pressing escape will return the control to it's original parent (code not shown for brevity).
The only thing that doesn't work is receiving global key presses (Del, Ctrl+Z, Ctrl+A) the ones that are declared for the Workbench and forwarded to the EditorPart. Is there any way I can hook into these or redirect them from the EditorPart to forward them on to the GraphicalViewer?
Thanks in advance
The short answer is you can't do that. Once you re-parent that composite out of the workbench window, it's totally busted. The system won't correctly deal with the part, as events (like activation, focus, setBounds(*)) aren't being processed.
The only supported way would be to open a new Workbench window with a perspective that only contained the editor area, and extending your org.eclipse.ui.application.WorkbenchWindowAdvisor.createWindowContents(Shell) method for that window+perspective combination to hide all of the trim you don't want, using org.eclipse.ui.application.IWorkbenchWindowConfigurer.
ex, in MyWorkbenchWindowAdvisor:
public void createWindowContents(Shell shell) {
if (isCreatingSpecialPerspective()) {
final IWorkbenchWindowConfigurer config = getWindowConfigurer();
config.setShowCoolBar(false);
config.setShowFastViewBars(false);
config.setShowMenuBar(false);
config.setShowPerspectiveBar(false);
config.setShowProgressIndicator(false);
config.setShowStatusLine(false);
}
super.createWindowContents(shell);
}
Also check out http://code.google.com/p/eclipse-fullscreen/ which has EPLed code in it concerned with running an RCP program with fullscreen support.
My suggestion is to try to approach this problem from another angle. Instead of listening for keystrokes in your code and acting upon them, define your own key binding scheme and then create commands and make them use this scheme. This would mean that you no longer have to listen for the key strokes in your code, but instead do whatever needs to be done through commands executed by these key strokes.