I have this problem bugging me for a little while now and I didn't find any help on SO or other resources.
In Eclipse Java EE (Version: Indigo Service Release 2 Build id: 20120216-1857), when double clicking a file (a class, or XML or whatever else) in the Package Explorer to open it in the editor, it will open a new tab every time I double click the file, even though the file has been previously opened in another tab. So for example, double clicking 3 times in a row on a single file in the Package Explorer will open 3 tabs in the editor for this single file.
I found some info about how to display search result in a common tab, or how to open a single file in two different editors, but nothing about this problem, I cannot find any setting to disable this annoying behavior.
Anyone got some clues about this problem ?
After putting back the default settings of Eclipse, it seems to be alright now. I will update this post in case the same problem happens later on.
Related
In an Eclipse based application (RCP), when double clicking on a file that appears in the project explorer, for the first file this will work – the associated editor will open. However, when double clicking again on a file, it will not open. If you click somewhere out of the Project Explorer and then return to the Project Explorer, then the second double click will work.
Note that right-clicking on the resource and selecting “Open” always works. In addition, in Package Explorer it always works.
I believe this is related to eclipse bugs 285239 and 256761.
Does anyone know of a way that I can overcome this problem, as the RCP developer. The file editor is a custom editor in one of my plugins.
The problem does not seem to happen to me with java files in standard eclipse for java development.
Thanks,
Eyal.
I solved the problem by implementing a setFocus method on the editor class. In the setFocus, I set the focus to some component. (To be precise in my case the editor was a subclass of SharedHeaderFormEditor so I set the focus to the active page).
The truth is that the specification of the setFocus method in IWorkbenchPart requires you to "assign the focus to one of the controls contained in the part's parent composite". It seems that the default implementation of setFocus in some cases did not do that (I don't know why, maybe I was missing something or for other reason).
Note that also setting focus explicitly to a control from within editor initializing partialy solves the problem.
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
I've followed all the suggestions here.
When I press return, I get a new line that is indented with tabs instead of spaces.
If I backspace to clear the tabs, and then press TAB a series of times, it correctly indents with spaces.
I'm pretty sure I have all my settings set up correctly. I created a new Code Style > Formatter policy for every language in the project, and specified to always use spaces. It seems as though these settings are partially active (ex: when I press tab), but inactive when I use return. I tried restarting Eclipse. I'll try restarting the computer now...
I'm using Mac OS X 10.9.2 and a Liferay Developer Studio (1.6.3.v201312111844) version of Eclipse (not sure which Eclipse build its based on though).
Can anyone think of another setting/solution to ensure that newlines are created with spaces instead of tabs? I recently saw http://editorconfig.org/, and I'm wondering if there's some interference.
Thanks for any suggestions
If the file has existing lines that are using tabs, then Enter will respect that and try to create new lines in a similar way (see this comment by topchef for a solution). Also, it could be something in Liferay Studio's proprietary settings is overriding Eclipse standard preferences (as suggested by user John).
Keep in mind that each type of editor in Eclipse can have its own preferences and perhaps that's what you're running into here. You can try to find them all by opening Preferences and searching for "indent" in the search field. That will show all the preferences pages where indentation can be configured.
Also note that the Formatter settings don't have any affect on as-you-type formatting; that's for when you select a file or group of files or part of a file and choose Source > Format from the menu.
I've seem to have lost the ability in my Eclipse to auto-correct errors in my source code lines.
For example, a line like this:
Date date = new Date();
has red jagged lines beneath the Date() part. Previously I could mouse hover over it see a popup menu of options to fix it. Now I all I ever get is a popup with the text "Cannot resolve to a type".
The only change I can think of that I've made and I don't know if it has anything to do with this problem, is that I started editing my .java files with an outside editor. Then focusing back into Eclipse I get a popup saying the source has changed and do I want to update so I say OK.
Sometimes I will edit inside Eclipse and sometimes i will edit the source outside of Eclipse. I'm not sure if this is a bad practice or not?
Its your wish to edit Java files outside or inside eclipse. But Java editor has many features which are very helpful to developers. I suggest to edit Java files inside eclipse only.If you find other editors are good or you used to it then no problem you can edit Java files out side eclipse also. The problem you mentioned in not related to it. But make sure that changes are applied before building project in eclipse.
Solution
This occurs whenever there are multiple classes are available with the same name in you build path then eclipse don't know which one to import by default. So keep the caret on the error line and press Ctrl+1. Then a eclipse gives options to user to import one among these. See the picture below. Choose the right one then error will disappear.
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.