How to programmatically reload a text editor in Eclipse? - eclipse

In Eclipse, if I change a file programmatically, and it is open in a text editor, it doesn't always reload, not even when refreshing the resource programmatically. How can I forcibly reload the text editor from code so that it show the changed file contents?

In your project explorer or navigator, you can right-click on the file that's currently open and select refresh. This has always worked for me, even when editing files with several programs. Make sure to click the file itself, not parent objects like packages or folders or projects.
Edit
Refreshing programmatically? I would look into an Eclipse scripting tool:
http://eclipse-shell.sourceforge.net/
I guess there was another one called Monkey, but it doesn't appear to be maintained.

I don't know of any possibility to programmatically reload the file.
Some editors (e.g. GMF editors) look for changes in the underlying files, and refresh themselves, but this is not required at all.
I don't think that a forced reload is an option implemented globally, as in some cases there could be some merging steps involved that can be quite erroneous.
My ideas to solve this:
Have a specific editor that refreshes its content when the used resource changes (this can be timeconsuming);
Or close the editors of the file and reopen them (this is ugly in the eye of the user).

Since the Luna release of eclipse there's no need to reload files with F5/manual Refresh.
Really nice, especially as there was a bug with the F5 key binding.

Related

how to remove google sign in button in eclipse

I'm facing a wierd problem. My eclipse, has a google signin button which is occupying some of the space which I do not want to happen. Initially it had "Sign-in to Google" text along with it. I've followed some blog post and set accordingly to show just the icon (I don't remember that blog post link).
But now, the icon is getting replicating .. it is being shown 12 times. It is actually creating childs :P
I've gone through all the options present in Customize Perspective menu, none of them had this button listed. Can someone help me in removing that google sign button from my perspective? One possible suspect is- my eclipse crashes when I suspend and wakeup my machine.
You can use the Window > Reset Perspective... menu command to reset the perspective to its default state, which might eliminate that toolbar and buttons. If that fails, I would create a new workspace and import the projects into it using File > Import > Existing Projects into Workspace.
If you want to try to salvage your existing workspace, it's possible to do so my manually editing Eclipse's internal file that stores your Workbench layout, but it's a bit tricky. Here are the steps I've followed to eliminate a similar repeated toolbar item:
Exit Eclipse.
Find the Workbench layout file, it's path is <workbench>\.metadata\.plugins\org.eclipse.e4.workbench\workbench.xmi. Make a backup of this file before you touch it - this is essential because it's easy to corrupt the file if you change the wrong things.
Open the file in your favorite XML-aware editor - most packages of Eclipse include the XML editor that works just fine1, but be aware that if you use Eclipse to edit the file you can't have Eclipse open on the workspace that contains the workbench.xmi you want to edit.
Find the section of <trimBars> nodes in the XML; from there you have to determine which <trimBars> node you need to edit. In your case it looks like a vertical one, probably with a side="Right" attribute.
Under the correct <trimBars> node you'll find multiple <chlidren> nodes, each with an elementId attribute that should help you identify it; you're looking for <children> nodes that are identified as something related to the Google plugin.
Delete the <children> nodes that seem related to the unwanted toolbar buttons. In your case, it appears that there is an entire toolbar that you might want to eliminate, so you might want to delete the entire containing <trimBars> node.
Save the file and start Eclipse on that workspace.
1Some packages of Eclipse include EMF tools that will open it in a special XMI editor that does not provide a view of the source, only a structural tree view. Depending on how you like to work with XML, this might be easier than editing raw XML.
This is not a perspective but a view. You can hover over that bar with the buttons and click Alt+Shift+F1 to check where this View comes from. Then you can either disable/uninstall the contributing feature (Help -> Installation Details) or check where the feature came from.
If it comes from the IDE, you can open a bug for it. If it is contributed from a third party plugin, contact the developers of that plugin.
There is an eclipse bug concerning duplicate view toolbar buttons in Luna that has recently closed as well. Maybe this solves your problem as well.
Edit: Taken from this bug:
root cause is that in Luna 4.4M5 WorkbenchWindowControlContribution.createControl is called twice, the
first time with a null value for
WorkbenchWindowControlContribution.getWorkbenchWindow() while it is
still being created. This is related to what has been reported here
https://bugs.eclipse.org/bugs/show_bug.cgi?id=427452
second cause is that my createControl(Composite parent) method was calling PlatformUI.getWorkbench().getActiveWorkbenchWindow() instead
of WorkbenchWindowControlContribution.getWorkbenchWindow(). This
resulted in an attempt to create a new Workbench Window, which
recursively calls createControl() again. This has already been
reported here https://bugs.eclipse.org/bugs/show_bug.cgi?id=366708

Eclipse treating file as plain text

I've got a small homework project, and for whatever reason Eclipse has decided to stop highlighting syntax or allowing intellisense or goto definitions or anything in this Main.java file. I've tried rebooting it, and the computer, but had no luck.
The thing that really has me confused is that it's still compiling and running the code correctly (eg, changes I make in Main.java are compiled and run - it's not running old Main.class files), so it's still in the build path ... right?
Any ideas?
Right click on the file in the Package Explorer and choose the Open With menu. You will probably find that Text Editor is selected, choose Java Editor to open the file with the correct editor.
The Open With menu selection is remembered so you should get the Java Editor in future, but equally if you choose the plain text editor that is also remembered.
I suggest finding a way to reset any setting you might have set by accident. Not saying that you did it. But just to make sure, just try it out. If you customized the preferences already, you could make some kind of note of the settings, then change it. If that doesn't work, let me know. Good Luck!
Copy the text somewhere, delete the file, and then add a new class (of the same name) and paste the text back.

The option to save a file is greyed out in Eclipse

I'm using Eclipse 3.7 on Ubuntu. Often, after editing a file, I cannot save it - the "save" option is greyed out in the menu and Ctrl+s seems to do nothing, even though the file has just been modified and the editor displays the asterisk before the file name in the tab header.
Changing the active tab to another file and then coming back to the first file "unlocks" the save option, which I can then choose.
What causes this behavior, and how can I fix it?
This is a reported bug in Eclipse. You can follow up and bring more information in the bug report in Eclipse's bugzilla.
The easiest workaround I could find was to just restart eclipse. Worked for me.
That can also happen when the Project Explorer view has focus (bug 211520)
The new Eclipse 2019-09 has fixed that issue
You can now save the active editor even when the Project Explorer has focus.
In cases where an extension contributes Saveables to the Project Explorer, the extension is honored and the save action on the Project Explorer will save the provided saveable item instead of the active editor.

In Eclipse, how do I refresh the icon decorators (per-file 1+ warning, 1+ error) in my Project Explorer?

In Eclipse, in the Project Explorer pane, each Java file will have an icon decorator, indicating whether that file has 1+ compilation errors, or 1+ compilation warnings.
I often find that these icon decorators are out of date with my latest file changes.
How can I force them to be up to date?
I try right-clicking on the project's top-level directory and selecting Refresh, but that doesn't help. Neither does restarting Eclipse.
I realize that one alternative is to use the Markers pane, but that gets me the entire list of all warnings/errors across all files. I'd rather know, see visually, which files have problems and which are clean.
You haven't said which language you are using and whether autobuilds are on or off.
In general, problem markers are only added and removed by your project's builder. If you are using Java, for example, that language has full automatic incremental build support, so the markers update whenever you save a file. Not all languages enjoy this; you may need to explicitly rebuild your project(s) to force an update.
If you believe a marker is out-of-date, or just want to hide it, it's usually safe to delete it from the Markers view; the relevant builder will reinstate it if necessary next time it runs.

SVN Export in Eclipse removes labels on tabs

I have a very strange effect when using subclipse with eclipse. Whenever I use Team->Export to export a file from the editor the export works fine, but the label of the tab of the file is removed.
Effect can be seen here: http://www.daspferd.de/img/tabs.png
Strangely enough it happens with php-files, css-files, html-files but NOT with javascript-files. So I'm assuming it's some kind of setting that I haven't found yet and not a bug in subclipse.
Anyone know where I can shut down this behaviour?
It could be a bug in the editors. If eclipse opens an editor on the exported file, it might not open it as an IFileEditorInput, and the editors therefore do not set the title correctly (that's the job of each individual editor implementation).
This is just a guess, but it would be consistent with some editors behaving ok and some not. It would basically be a missing feature in some of your editors.