I have installed Eclipse & CDT plugin on newly installed Ubuntu. The indexing is set to "Fast indexing" which is recommended ("Full Indexing" seems to have marginal difference).
At so many places, if I press 'F3' ('show declaration') on any class name or include file name, the cursor remains stand still and it doesn't lead to the declaration. However, it works for standard files and symbols like, stdio.h, std::vector and so on.
For example, I have 2 files,
/home/myself/Workspace/Project/X/Y/include/file.h
/home/myself/Workspace/Project/X/src/file.cpp
I am not able to see any declaration of any class or variables displayed in file.cpp which are residing inside file.h. Even pressing 'F3' on #include"file.h", I am not able to go to file.h.
Eclipse Workspace is created at Workspace folder the C++ project is created at Project folder. To store the include path, I have followed this procedure in Eclipse:
Project -> Properties -> C/C++ General -> Paths and Symbols -> Library and Paths -> Add "/Project/X/Y/include/file.h" (used 'Workspace' and 'FileSystem' tabs both)
But still no luck. I have done enough searching on internet and SO, but couldn't find anything useful. Note that, I am using eclipse only for code browsing and not for building the code as of now.
Ok, got it working. Actually whatever include paths I have included in Paths and Symbols are redundant and they make no difference as everything under Workspace/Project will be indexed.
The solution is very weird and it's related to scalability, which I came to know from this link. In Eclipse go to,
Window -> Preferences -> C/C++ -> Editor -> Scalability -> "Enable scalability mode when ..."
Set a huge number such as 500000 and press "OK". The problem was solved! For my case the actual set value was 5000 and the source file I was seeing was of 16k+ lines.
Related
Just getting hands on with NetBeans 8.0.2. Wondering if the IDE has similar features as Eclipse or Visual Studio like
Track current file in Projects explorer - When working with large projects, with lots of files open, if I want to navigate to current file in projects window it is getting difficult.
On top of it, the project explorer is showing the folders/files in a case sensitive manner resulting difficult to locate the exact file/folder.
Is there a settings or two to control this behavior?
For the first part:
use the option "View -> Synchronized Editor with views" to automatically select the current file in the editor in the project window.
Alternatively (what I prefer) use "Navigate -> Select in Projects" to manually select the current editor file in the project window .
You can find more information about navigating in the IDE in the manual:
http://docs.oracle.com/cd/E50453_01/doc.80/e50452/work_java_code.htm#CIAGADFI
Regarding the second part: Java is case sensitive. MyClass is something different than MyCLASS so it has to treat the file names as case sensitive.
I'm using Ubuntu 12.10 and Eclipse Juno. This happens frequently: When I put focus in eclipse editor window, I can input few words in editor at the beginning, and then undo several times, Suddenly it happened that, I can't input any word in eclipse, that's strange problem.
Then, I change to other program and input anything, After that, back to eclipse it can accept my key again. It get me so frustrate.
Any one knows this problem? I am using desktop pc, memory is 1G.
This may help;
I guess you have lots of projects in your workspace and Project->Build Automatically option was enabled by default. Disable this and use Project-Build All or Project-Build Project commands before you start debugging your application OR If possible create two workspace and move some of your projects to other workspace. Note that you can open two instances of Eclipse on two different workspaces simultaneously.
Increase heap space for Eclipse.
Its also possible that you installed many plug-ins in Eclipse. You can disable unnecessary plug-ins to load on eclipse start up as shown below
Edit
Two more options.
1. Disable all options in **Highlighted** category of preferences. Restart eclipse.
2. Delete **.metadata** in your workspace and restart eclipse. Note!!!. All you preferences will be lost!!!
I found this problem; It is scim input method conflict with XIM(X Input Method) method.
Solution 1,
just right click in eclipse workspace -> select Input Methods -> SCIM input methods, that's OK. But, Every time you should do it while opening another file.
Solution 2, make scim as default system input methods.
Edit /etc/X11/xinit/xinput.d/scim as below:
XIM=SCIM
XIM_PROGRAM=/usr/bin/scim
XIM_ARGS="-d"
XIM_PROGRAM_SETS_ITSELF_AS_DAEMON=yes
#GTK_IM_MODULE=xim
#QT_IM_MODULE=xim
GTK_IM_MODULE=scim
QT_IM_MODULE=scim
also, add x95input file to /etc/X11/Xsession.d/95xinput
/usr/bin/scim -d
XMODIFIERS="#im=SCIM"
export XMODIFIERS
export GTK_IM_MODULE=scim
Hope this can help others.
I found it.
I googled and found the answer
The answer is:
Right click in Editor area InputMethods-Scim
*Editor area is where you write code
The momentics IDe for BB10 has encountered a problem or at least I believe that al my inclusions appears as unsolved. when I compile the app it compile correctly and everything works pretty well. But the problem is that I need to import some libraryes like #include and as long as this libreries are shown as insolved inclusion I cannot declare any object of those types.
Does any one know what can be this and how to solve it.
Things done berofe:
I've tried cleaning the workspace and creating a new project and also the new project works perfectly, also I've tried going to configure add and and some libraries. this works but only works for specific libraries, not at all for libraries.
Edit 1: As I saw on other posts, I've reinstalled the 10.1 sdk that is the one I need, but no luck
In the Workspace's Project Explorer pane, right click the project, and then select Build Configurations -> Set Active -> Simulator-Debug (Just to be sure.)
From menus, Window -> Preferences. In the Preferences dialog's left pane choose C/C++ -> Indexer.
To get intellisense to work when authoring well before making builds, under Indexer options, check boxes Index source files not included in the build, index unused headers, index source and header files opened in editor. And under indexing strategy check both boxes, automatic update and update after every file save.
Finally, under Build configuration for the indexer select the Use active build configuration option (Just to be sure.).
For class declaration in header file, the erratic feedback from IDE will disappear (as of Momentics 2.1.2) only after cpp file for implementation, that includes the header is saved.
If modifying header, after setting up as above, right-clicking on the project in Workspace pane -> Index -> Rebuild should work.
Sometimes, in Eclipse , i press a combination of keys which take me to the editor page that shows contents of my .class file (bytecode). I never seem to be able to remember what that key combination is.
Can someone please let me know?
Or in other words, how can one see own bytecode?
Eclipse's default class file viewer shows the source (see VonC's answer) if it has been associated with the binaries, otherwise it gives a javap-like view of the class (with an option to attach source). I'm guessing it's the latter that you are looking for.
I've never found a way to cleanly force Eclipse to show that output rather than the linked source. What you probably want is an Eclipse plug-in that provides Javap like functionality (or an interface to javap). Look for plugins stating they "disassemble" (as opposed to "decompile," like jad).
Barring a plug-in, you could probably configure an external tool to perform javap but it might not play nicely with other eclipse features.
Edit: Let me be clear about the above: If you hit F3, Eclipse does the following (generally, the actual procedure might be slightly different):
Resolves the target (if you are selecting a Java file, it will be the Java file itself; if you are selecting or your cursor is over a class name it will be the class declaration, similar for a method declaration, etc).
Searches the build path (same project first) for a Java file containing the target. If found, opens up an writable editor displaying that Java source file.
For class/method declarations, it continues searching references on your build path for a class file that contains the declaration. If it is found, then
a) If the class file has had source attached to it, open up a read-only editor of the linked Java file.
b) If the class file does not have source attached to it, then open up a read-only panel showing the disassembled (javap-like) bytecode of the compiled class file.
My guess would be that you're thinking there's a dedicated key sequence to 3.b), but I don't think there is. But again, I would love to be proven wrong here.
Using the following external tool configuration we can view java byte code in eclipse with the help of javap:
To get the above pop-up select Run option and select External Tools and select External Tools configuration...
${system_path:javap} is used to locate javap in the JDK used by the Eclipse. You can use an absolute path to javap instead.
${project_loc} returns the absolute path to the project. This is used, since I could not find a pre-define variable to use, to locate the .class file of a resource, and that's why javap runs in the project's directory instead of the directory containing the .class file.
Among the arguments passed to javap:
bin is the default output folder for Eclipse projects. Change this to build/classes or whatever is used by the project. Note, the value is relative to ${project_loc}; you can specify absolute paths instead.
${java_type_name} is used to obtain the selected class name.
You can select a Java file in the Project explorer view or Project navigator view, or even a Java type in any of the views, and then run the external tool. Note - this approach doesn't work quite well when you select a method, an inner class etc. and then run the tool, as they are not resources on their own, leading to the scenario where ${project_loc} will be empty.
Source
Dr. Garbage Tools is a suite of Eclipse Plugins released under Apache Open Source license.
Install Bytecode Visualizer using Eclipse Marketplace.
To view a bytecode:
Right click on .java file, select open with and select other you will get the following popup:
Search "Bytecode Visualizer" and select the option it opens the file as follows there you can find Bytecode option as shown:
Enhanced Class Decompiler
"Window > Preferences > General > Editors > File Associations"
Change default to your for both .class association.
"*.class" : "Class Decompiler Viewer" is selected by default.
"*.class without source" : "Class Decompiler Viewer" is selected by default.
You can use ASM 4.0 Plugin.
Installation
The Bytecode Outline plugin can be installed from the Eclipse Update Manager with the ObjectWeb Eclipse Update Site http://download.forge.objectweb.org/eclipse-update/
Alternatively, the plugin can be downloaded from the ObjectWeb Forge site, and manually installed in the Eclipse plugins directory.
Usage
To see the bytecode of the current .java or .class file:
Window -> Show View -> Other -> Java -> Bytecode
To compare the bytecode of two .java or .class files:
select two *.class or *.java files -> right click -> Compare with -> Each Other Bytecode
or
select one *.class or *.java file -> right click -> Compare with -> Another Class Bytecode
http://asm.ow2.org/eclipse/index.html
Well... if the .class is selected in the Navigator View or Package Explorer view, a simple F3 is enough to open a decompiled version of it in the editor.
As hinted at by user833970: The Bytecode Outline plugin: http://andrei.gmxhome.de/bytecode/index.html
At its base, it provides a "bytecode" view for the currently opened Java file which is what you were looking for.
However, you can also assign it to load any random .class file instead of the default .class viewer, and it surpasses it in many ways. For example, this viewer actually jumps to the right spot in the bytecode if you click on a member in the Outline view.
Download links (for dropin use) can be found at the afore-mentioned link, the update-site is http://andrei.gmxhome.de/eclipse/.
If you are really interested in the bytecode there is a eclipse plugin that lets you open and edit the bytecode of a .class file using a text editor.
https://github.com/itemis/jbc
I've tried several different solutions for this.
Bytecode Visualizer (available here: https://sourceforge.net/projects/drgarbagetools/ ) is, in my opinion, the best solution. It neatly displays the output and makes clear how it links to the source code. I've noticed a few minor misinterpretations on some of the bytecodes, but you can get the gist of it.
Unfortunately, it doesn't seem to support Neon at time of writing. It does support Mars, though.
I spend some time customizing the colors for syntax highlighting in Eclipse (Java, JSP, HTML, CSS, etc.) but whenever I try to export these settings via File|Export|General|Preferences and reimport them, the settings never completely get imported back. Some colors are restored and others are left unchanged, leaving me in an 'in between' state - very frustrating.
I'm using Eclipse 3.4 Ganymede, by the way.
Has anyone found a reliable way to save and restore Eclipse syntax highlighting settings?
I finally figured out how to do this.
I just wanted to mention beforehand that I did try to start with a fresh Eclipse install, export the preferences to a .epf file, change just one single setting, export again, and compare the files. To my surprise, trying to import settings from a minimal .epf file did not work reliably either.
The solution that worked for me was to copy these files: {Eclipse workspace directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs
I tried a fresh Eclipse install on another machine and after copying those files over, all my settings were restored perfectly.
The solution was to copy SOME - not all - of the files from {workspace}/.metadata/.plugins/org.eclipse.core.runtime/.settings/*.prefs into my other workspace.
In particular (per the https://stackoverflow.com/questions/96981/color-themes-for-eclipse thread):
org.eclipse.jdt.ui.prefs = Syntax Coloring
org.eclipse.ui.editors.prefs = Text Editors
Copying other files caused things to break.
There are a couple of notes to add:
I had to copy the aforementioned pair of files several times before I got the correct syntax coloring.
Be sure to close the workspace, if it's open in Eclipse, before copying the files.
This worked with Eclipse Helios.
If you want to be a little more fine grained on what you migrate, the syntax highlighting rules are the lines starting with semanticHighlighting on workspace-indigo/.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
Doing this, I was able to migrate my syntax highlighting from Helios to Indigo
I'm using JBoss Developer Studio 10 with the Eclipse Neon 4.6 engine.
All .prefs files are inside this path:
/workspace/.metadata/.plugins/org.eclipse.core.runtime/.settings
Update: I found a similar structure on this path too:
\RedHat\JBossDev\studio\configuration\.settings
It's my IDE folder plus \configuration\.settings
I recommend search for org.eclipse.*ui*.prefs instead *.prefs to refine your result.
The principal config files are:
org.eclipse.jdt.ui.prefs
Java Syntax Color Settings
org.eclipse.ui.editors.prefs
Text Editor Settings
org.eclipse.cdt.ui.prefs
Formatter Settings
org.eclipse.wst.jsdt.ui.prefs
JavaScript Syntax Color Settings
org.eclipse.jst.jsp.ui.prefs
org.eclipse.wst.css.ui.prefs
org.eclipse.wst.html.ui.prefs
org.eclipse.wst.json.ui.prefs
org.eclipse.wst.dtd.ui.prefs
org.eclipse.wst.xml.ui.prefs
org.eclipse.wst.xsl.ui.prefs
If have a problematic workspace:
Copy the files above
Create a new workspace
Copy and Replace that files in your new workspace
This will recover perfectly your custom editors color settings. For me worked very well.
Eclipse CDT stores 'Syntax coloring' in the file org.eclipse.cdt.ui.prefs
This is located for example here: C:\eclipse\workspace.metadata.plugins\org.eclipse.core.runtime.settings\
Copy and paste over the top of the one in your new eclipse instance. This worked for me when moving from 3.4 to 3.5
I would export the preference before modifying the color, and then after.
That way, you would be able to isolate the specific rules of an eclipse preference file into one smaller file and:
check if some colors not restored are indeed represented by a rule
the import of a smaller preference has any effect on the previously unchanged settings.
That kind of strategy can be further refined into several small settings files (one for Java, one for JSP, HTML, CSS, ...), in order to better analyzing the potential side-effects when re-importing those settings.
I have had success in importing Eclipse Helios's syntax highlighting rules by copying the file:
.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.jdt.ui.prefs
from the source workspace to the target workspace. It seems this file also contains Eclipse's code formatter profiles and code templates.
Environment:
Version: Helios Release
Build id: 20100617-1415
(on linux)
Once Michael Bosworth's answer helped me to some extend and I voted up. But now I see some obligation to answer it myself, because copying these two files are not enough. Let me explain why.
First, these files contains lines irrevelente to syntax coloring.
Second, syntax coloring for other editors are located elsewhere, for example, those of XML files are in
org.eclipse.wst.xml.ui.prefs
and those of HTML files:
org.eclipse.wst.html.ui.prefs
JSP pages?
org.eclipse.jst.jsp.ui.prefs
, etc.
Third, when we change font colors, usually we change background colors, line highlighting colors, etc. to get a clearer view of codes. This involves more files.
If we search *.pref files in path
/workspace/.metadata/.plugins
we can find all preferences files where we can locate all lines of coloring settings. But by copy-pasting all these files to another workspace can also trigger problems, for they are not exclusively syntax-coloring-related. Moreover, when we are switching between two versions of Eclipse, unexpected problems may arise.
So, the safest way is:
Create a new workspace if you don't have one.
Open all *.pref files we find in the workspace one by one,
Copy those lines containing color codes,
Find the same file in your new workspace,
Replace the color part by existing one. Or, set the colors in Eclipse, by assuming the corresponding options according to properties' name. All color codes are RGB based.
EDIT: (2017.02.24)
Eclipse Mars has a plugin Oomph, which can record your preference settings to provide seamless transmission of your preferences. When you activate it, every time you change a value, it prompts to ask you if you want to record it in Oomph, providing you the exact line in the corresponding file where your new value is stored. So, when you install Oomph, you can:
Change the settings of your font face, font size, background color, etc.
In the prompt windows of Oomph, take note of the location of your new settings. (Because if you tell Oomph to remember your settings, it will not prompt never again, so you may only see this windows once.)
I have deleted recently changed *.prefs file from the following dreictory \myworkspace.metadata.plugins\org.eclipse.core.runtime.settings\ and imported existing exported preference.
I am the first person, who answer for this question as per my knowledge :), Cause even I struggled lot.
Thanks
I faced the same problem few days ago.
The easiest way to restore the defaults is to import the default theme again, which you can find under:
http://eclipsecolorthemes.org/?view=theme&id=790