I have a problem with custom keybindings in eclipse, since it seems i can't find anyone with the same problem i guess i am the one missing something.
When i define customised keybindings in Windows->preference then General->keys, it works just fine. (exemples: changinq redo from ctrl+y to ctrl+shift+z and unbinding ctrl+art+p).
the problem: When i restart the eclipse ide, those bindings are reset.
I thought my workspace was corrupt so i tried on a fresh eclipse install with newly created workspace and project... same thing.
runing eclipse neon (4.6) but problem was also on eclipse mars (4.5.2).
all under windows 7.
Thank you.
Ok, I know what i missed:
Oomph "preference recorder". (tadaaa).
(in windows->prefereces, then Oomph->setup tasks->preference recorder.)
It is strange that i never bumped into this before. I had this probleme for weeks and "googled" a lot about "eclipse key bindings", but only found out when i clicked on "Review IDE configuration settings - enable preference recorder" on the new neon Welcome view.
Anyway, Problem solved.
Related
I am running Windows XP and Eclipse 4.2.2 Build id: M20130204-1200 and I have lost my Debug and Launch tool bars. I have tried Windows>Reset Perspective (original values) and Window>Customize Perspective's (Tool Bar Visibility and Command Groups Availability) tab options. I have tried the Layout option on Debug view. All failed to bring them back. Right now, I am looking at Tool Bar Visibility tab and a message that says: <"Debug" cannot be made available because it is in the unavailable "null" command group.> However, the Debug checkbox in Command Group Availability is checked.
I have also tried right-click and Reset on the perspective buttons.
Switching to another eclipse installation (same machine) did not help either.
Rebooting does not help.
Are there any text configuration files where this data is stored that can be manipulated outside eclipse?
I had this problem in Eclipse Kepler, it turns out it was caused by PyDev plugin. I fixed it by uninstalling the plugin and right-clicking on the Debug perspective button and selecting Reset.
I had already installed a fresh copy and the problems persisted. But, encouraged by user714965 comments, I tried again but that did not resolve the issue. Then, I threw away all eclipse installation folders (to recycle bin), re-installed fresh copy, and the problem persisted. Then I started a new workspace, and it seemed like the tool bars were back. Then restored previous eclipse installations and they had the Debug toolbar as well!
I am thinking somehow the customization config files were broken. It would be nice to know where the these files are stored (my original question): Are they global for each user on the machine or are they workspace specific? It seems to me that some customizations are global, while others are project specific.
May be it is time to try the new Android Studio :-)
Seems as your eclipse is broken. The fastest way to get it back running will be downloading a fresh copy from eclipse.org. You can continue using your current workspace so your settings will remain. But you have to re-install all plug-ins... I'm always keeping a backup of a fresh release with the plug-ins I'm using. I would suggest you to do the same in the future.
What should I do, if the "Open Call Hierarchy" is broken (empty for every method in a project)? It only shows the name of the method I wanted to see the call hierarchy for. This happens for all methods I try, even though they are all called by other methods.
It is very useful for code navigation. I do not know how to work without it!
I've tried:
Opening eclipse.exe -clean -refresh
Restarting Eclipse
Closing and reopening the project
Updating the project
Renaming the .metadata file
I've checked that it searches the whole workspace, and there are no filters on.
The following may help:
Calling eclipse with eclipse.exe -clean -refresh forces Eclipse to rebuild the index. After that the feature worked again.
Closing and re-opening the project.
I also tried the suggestions above, as well as the hint given here: http://mschrag.blogspot.co.at/2009/01/open-type-cant-find-your-class.html
Nothing worked until today when I found out that I am a donkey...
I once configured a filter in the "Call Hierarchy" view and so no entries were shown because filtered out. Once I removed / disabled the filter everything worked fine again.
When you go to the eclipse bug report for this issue, somebody says, you should install over the Market place the Java 12 support.
When I installed it, it was working properly again
Also, you can try to delete the workspace and get it recreated. Make sure all your projects are backed up.
For Kepler and PDT (PHP IDE) it is broken in at least PDT 3.2.0 and 3.3.0 (tried them both). The fix is in 3.3.1 and updating to that was all I had to do get the call hierarchy working again.
(apologies, I'm not yet allowed to add comments, however this should prove handy to many)
In my case it seemed my workspace was contaminated.
Opening/closing projects and starting with clean did not fix. I had to start off a new workspace.
Fedora 20, Eclipse Kepler.
I have the same behavior with eclipse Kepler (4.3.2).
I found out, that there is a bug with methods with signature of:
void get(Object o)
Object get(Object o)
In the eclipse Error Log view I find the following exception:
java.lang.NullPointerException
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.directoryTable(ClasspathSourceDirectory.java:52)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:109)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findClass(JavaSearchNameEnvironment.java:146)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findType(JavaSearchNameEnvironment.java:185)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:145)
at org.eclipse.jdt.internal.compiler.lookup.PackageBinding.getTypeOrPackage(PackageBinding.java:197)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage(Scope.java:2799)
at org.eclipse.jdt.internal.compiler.lookup.Scope.getType(Scope.java:2556)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getType(MatchLocator.java:899)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding0(MatchLocator.java:955)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.getMethodBinding(MatchLocator.java:907)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.matchMethod(MethodLocator.java:327)
at org.eclipse.jdt.internal.core.search.matching.MethodLocator.resolveLevel(MethodLocator.java:664)
at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:209)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1699)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1143)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1184)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1301)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:95)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:231)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:515)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:584)
at org.eclipse.jdt.internal.corext.callhierarchy.CallerMethodWrapper.findChildren(CallerMethodWrapper.java:155)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.performSearch(MethodWrapper.java:301)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.doFindChildren(MethodWrapper.java:232)
at org.eclipse.jdt.internal.corext.callhierarchy.MethodWrapper.getCalls(MethodWrapper.java:84)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.getCalls(DeferredMethodWrapper.java:65)
at org.eclipse.jdt.internal.ui.callhierarchy.DeferredMethodWrapper.fetchDeferredChildren(DeferredMethodWrapper.java:79)
at org.eclipse.ui.progress.DeferredTreeContentManager$1.run(DeferredTreeContentManager.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)
In the end, it looks like a bug in this version:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=401272
I assume, that upgrading at least to version 4.4 (Luna) will solve this problem.
In my case I was trying to get the call hierarchy of a method in the derived class of an abstract class. The requested method was declared abstract in the base class.
When I opened the call hierarchy directly on the abstract method instead of the implemented one, everything worked well. (Eclipse Neon).
My problem was that Open Call Hierarchy was searching only the project not the entire Workspace.
So I had to click on the small down arrow (in the Call Hierarchy view window on the right; it is the "View Menu" arrow -- a triangle pointing down) in Call Hierarchy view, set the Search Scope > Workspace.
Tried everything in all the answers here, but none of them worked for me. Later I figured out that this was a bug in Eclipse 2019-03 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=545293). Try to upgrade your eclipse or install a newer version.
For me installing a newer version(latest version Eclipse 2019-09) solved the problem.
I tried many answers all were great, it helped many except few and I was in few.
My eclipse version is 2019-03(4.11.0). This is which has a bug. Which can be fixed by add-ons.
Go to the Eclipse Marketplace and search for plugin java 12 Support for Eclipse 2019-03(4.11)… and install it. On completion of installation restart the eclipse. Hopefully this will fix the problem. Have a nice day.
If the call Hierarchy is not opening, it might be because of the project is not imported as a java project, rather it would be displayed in the file stucture. You may want to enable the project facet through:
right click on the project -> project facet.
If you dont see anything listed, you need
configure the project facet -> Apply -> ok.
I'm using Juno on macOSX mountain lion. CMD+W doesn't close editor windows, but it gives 'put breakpoint' for some Ocaml plugins. This is strange because I can't find anything OCaml in my plugins, neither from Help->Install New Software->already installed, nor the folders in the filesystem. I must have had the plugin before but already removed it.
Preferences->General->keys shows the right binding (CMD+W means closing and NO conflict), but it doesn't work. If I change it to another binding, that will work. But CMD+W is convenient.
The weird thing is that after removing ~/Library/Cache and ~/Library/Preferences for eclipse and installing a fresh copy, the problem persists. This is what drives me crazy.
Does anybody know what is the problem? What else can I remove to set eclipse to factory default?
Thanks
I tried to use another workspace and it worked fine. So I found in my current workspace a .metadata/.plugins folder and removed that. That was the reason.
Caution: this resets everything and removes all plugins.
When I select a folder in the Eclipse Project Explorer, the 'explosion' often will cause a file to 'moved' out of its current folder - sometimes even to another project - causing errors in the re-compilation (thankfully).
Does anyone have a solution to this 'tenderness'? (If relevant, I am using Ganymede under Eclipse 3.4.2 with the Android Plugin.)
My theory is that the OP is accidentally doing a drag-and-drop and moving files. I couldn't see a simple way to turn off drag-and-drop in the preferences editor.
I worked On Eclipse Ganymede in Linux
I think there is problem with your Setting of editor
I work with Eclipse a lot, I've used Ganymede for over a year under Linux and sometimes Windows, and neither I nor any of my colleagues have ever seen such a problem.
My guess is that there are problems between your mouse and display drivers, i.e. you are inadvertently clicking on other things when you are meaning only to explode. Can you try opening folded branches by selecting the item and hitting the + key rather than clicking in the GUI?
I'm running Eclipse Europa (3.3). I leave the "Build Automatically" setting, under the Project menu, on all the time. Once in awhile my code isn't compiling, and I puzzle over it and then pull down the Project menu ... lo and behold, it's not set anymore. What gives? Is this a bug, or is there something else I'm doing that could cause it?
Edit: I am running the regular Java developer installation, plus Subversive and its connectors, Jetty Launcher, and I believe no other plugins. Other people at my workplace have had the same problem.
Edit: I am still having this problem once in a blue moon, only now I'm using Eclipse Galileo (3.5) for Windows. I haven't had this problem in Galileo for OS X, neither in Cocoa nor Carbon, but I have not used that for as long.
With Eclipise Mars.1 (4.5.1), Oomph may be the culprit. Eclipse Oomph supports automatically disabling Build Automatically with entries in
On Windows
%USERPROFILE%\.eclipse\org.eclipse.oomph.setup\setups\user.setup
If you want to disable this Oomph behavior try deleting the following setting
"Eclipse->Navigate Menu-> Open Setup menu entry-> Open User menu entry", a Preference Task under "User Preferences -> org.eclipse.core.resources -> description.autobuilding"
I learned about this setting by posting to the Oomph Eclipse Community Forum on Feb 8th, 2016. I posted a question titled "Oomph Defect? Build Automatically Keeps Getting Disabled". Ed Marks replied the same day with details about Oomph's support for managing the Eclipse "Build Automatically" setting.
https://www.eclipse.org/forums/index.php/m/1722751/#msg_1722751
I don't have eclipse right here to test and make sure but here is an idea.
Is any of the project or even workspace file in SVN ? if they are and they were uploaded with auto build disabled that might explain it
You update and overwrite your settings. This doesn't become apparent until you restart eclipse. this would also explain why other people at your workplace experienc this. it would even explain why some don't : thay are the ones who are careful what they update and don't allow eclipse to overwrite their own settings plus the ones who actually prefer to have autobuild disabled :)
I had the same problem and when I looked at the Source tab under Java Build Path (under the menu Project > Properties ) there were some source directories that didn't exist anymore (marked with a red X). After I deleted them, compilation worked fine and all new .class files are under the bin folder.
Strange. Is there perhaps a plugin installed that turns this off without your knowledge?
Maybe there is some conflicting shortcut. For example, some duplicated shortcut may be toggling it.
I am running 3.4 and I also have this mysterious behavior. I had it in 3.3 as well. I use CVS not SVN. Does not seem to follow a pattern just once in a while it gets switched off and then weird confusing stuff happens until I remember to check it and switch it back on. I am almost to the point where I want to write a plugin to always turn it on when eclipse loads.
When installing Google Plugin for Eclipse, 'Google App Engine for Android' is also installed.
For me, I uninstalled 'Google App Engine for Android', which I didn't need, and solved this problem.