Hi.
As you know, if there is already a Run configuration for a given
class with main type, Eclipse gives parenthesis and number at the
tail of the class name as in the attached image.
But even when there is no preexisting class with conflicting name,
why do I see it with paranthesized number at the end of (main type)
program name, like program(1), program(2)?
Do you have any explanation for this?
In the Launch Configurations window, there's a filter button in the toolbar (the "triple arrows" icon at the top of your screen shot). Clicking that drop-down allows to filter out (or not) various types of launches, including those that belong to closed or missing projects. If you un-check all of the filters you should be able to see the conflicting launch that's causing the name conflict.
I have had this before in Eclipse where I had a project with a runnable class (lets say the class was called MainRun) and then I close or delete the project from the Eclipse workspace. The MainRun run configuration disappears from the "Run Configurations" list. But if you later create a new project with a class called MainRun that you want to run, it somehow remembers that you used to have a configuration called MainRun, even though it is no longer in the list, and so your new one has to be MainRun (1). Could this be what is happening to you?
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
While debugging and keep pressing F5, if the source code does not exist, eclipse will open a new window declaring that the source was not found.
How can I make eclipse to only try to step in the code (while I am pressing F5 all the time) if the source code exist and if it does not exist, it would just automatically step over it instead of this "Source not found page". Is this possible?
The best you can do is to use Step Filters. Step filters prevent the debugger from suspending in specified classes and packages when stepping into code. Step filters are established with the Java > Debug > Step Filtering preference page.
=> i.e. you need to manually exclude types or packages for which you do not have source.
A quick way to keep adding step filters as you go along - in the Debug view, the selected stack frame's package or declaring type can be quickly added to the list of filters by selecting Filter Type or Filter Package from the stack frame's context menu.
Is there any way to remove binary references from "call hierarchy" (Ctrl-Alt-H) ?
Our project setup is such that for many members we have duplicated references (one reference from source file and one from the jar file with class compiled from that source file). The navigation is inconvenient and I wondering if any ways to fix that is available.
Call hierarchy can be limited in scope to a working set. You just need to set one up to exclude all your libraries.
If you click on the white down arrow in the top right of the Call Hierarchy window a popup menu will appear. Choose Search Scope/Working set and then select or set up the working set you want. A working set can include a source folder or a jar. Once set up your working sets will appear at the bottom of the Search Scope menu so you can access them quickly in future.
I've discovered another way to accomplish this, and since this question is one of the top results in google, I thought it would be good to add it as an answer.
In the Call Hierarchy view, one can click the 'View Menu' (the downward facing arrow) and select "Search In...". In the window that pops up, the user can un-check the options they want to exclude. For example, I only have 'Sources' and 'Required projects' checked.
I have what appears to be a very annoying problem. When compiling a project in Eclipse, I see no Console that shows the invocation of the Java compiler and the build results (as in NetBeans).
If I, for instance, import an existing project into Eclipse and invoke Project->Build Project, is there a view that will show me results of the compilation? While I know that my project contains a number of files that have errors, invoking Build Project shows no visual result/progress of the compilation. It does not show the list of errors so that I can quickly jump to them.
I'm aware that there is a "Problems" view, which shows a list of problems (and not just compiler errors) in all projects and not the particular project that I am working with, which makes it very inconvenient to locate and jump to source of the problem.
You can configure the problem view to show only problems in the current project:
Click on the small triangle at the far right of the view.
In the popup menu, select "Configure Contents..."
Select each item in the "Configurations" list and click on "Scope: On any element in the same project"
If you want to see the compiler working, you need open the "Progress" view.
Since Eclipse JDT provides its own built-in Java compiler, you generally do not see the invocation of Java Compiler.
The built-in Java compiler is tightly integrated with Eclipse and JDT, and provides the source indexing that enables powerful IDE features such as refactoring and quick fix.
Plus, it enables incremental build in background after each file modification, hence no visible "java" invocation.
You can replace/complete the java compiler with a javac` call of your own:
For instance, Using Alcatel-Lucent nmake with Eclipse JDT does precisely that, and uses a configuration launcher (which you can instruct to show a console):
You will need to add that special builder in the "builder" section of your project.
Do not forget you can create many "Problem view", and set one of them to show only problems for your current project.
Select: "on any element in same project"
Goto Windows->Show View->Console
or
Alt+Shift+Q,C
Console appears in tab with Problem view
Your question contains a couple of assumptions that you might want to re-think.
It does not show the list of errors so that I can quickly jump to them.
Errors are flagged in the edit window while you are editing. You can fix them on the spot, without having to "jump" anywhere.
If you drop an entire source file into your project, you may not be in an edit window on that file. (And, of course, that's not standard Eclipse usage.) The simplest way I know do deal with that is simply to "Refresh" the project and look in the Package Explorer view to see whether there are any errors detected (which will happen immediately if you "refresh" a file into a source folder). Double-click on any files which show an error icon and look at the right-hand side of the edit window to see exactly where the errors are.
I'm aware that there is a "Problems" view, which shows a list of problems (and not just compiler errors) in all projects and not the particular project that I am working with...
Unless you are using multiple projects, with inter-project dependencies, I find it useful to close all but the current project on which I'm working. Then the "Problems" view is specific to the current context.
Finally, I'd recommend looking at the Mylin "getting started" page for other hints on how Eclipse can help you focus on the current task.