Community
Participate
Working Groups
1. Open the C/C++ perspective and activate a task. 2. Open the project explorer view and enable 'Link open editors with content in the Navigator' and enable 'Focus on Active Task' buttons on top. 3. Open a C++ class's .cpp or .hpp file in your editor, visit several functions or member variables and see them appear in the Project Explorer. 4. Now click on a function in the project explorer 5. The editor's cursor goes to the first function in your file and the clicked function is not highlighted. 6. repeat: click on other functions, no response in the editor. Workaround: instead of clicking once, click and hold the function and then move (ie drag) your mouse pointer slightly. The editor's cursor jumps to the clicked function and it gets highlighted. Workaround: Disable 'Focus on Active Task': independent of the 'Link open editors...' option, clicking a function in the project explorer lets your editor's cursor jump to the clicked function. This bug really hurts 'coding at the speed of thought' :-)
Moving to CDT. I believe the Java package explorer explicitly filters selection events that were triggered programmatically to avoid the jumping cursor problem for Java.
This seems to work for me in general. Could you provide a sample file?
Created attachment 120469 [details] mylyn/context/zip I'm not sure how attaching contexts works, but I copied the context of my bug-causing task to this task. You'd probably need the source code as well ? This context applies to an svn project on: svn co http://svn.mech.kuleuven.ac.be/repos/orocos/trunk/ocl orocos-ocl (so project name is orocos-ocl). You clearly don't need to build that project to cause this bug, just check it out, activate the context and see that 5 functions are shown in the Project Explorer (in orocos-ocl/deployment/DeploymentComponent.cpp/<OCL namespace>/...). Click on any of these to see that the 'cross-referencing' is broken. Thanks for looking at this, Peter
Just a thought: could it be because the files change outside of the task ? I'm using git to manage the code and often, a file is changed outside of a task. Maybe the task gets confused when functions change location within a file, In that case it would be again a Mylin bug... Peter
(In reply to comment #4) > Just a thought: could it be because the files change outside of the task ? I'm > using git to manage the code and often, a file is changed outside of a task. > Maybe the task gets confused when functions change location within a file, In > that case it would be again a Mylin bug... > Peter What do you mean by "change outside of the task"? Are the files modified by another process (git)? In this case, neither CDT nor Mylyn can be blamed. Out-of-sync resources will always cause issues with Eclipse. When resources change outside Eclipse, you need to explicitely refresh them first.
(In reply to comment #5) > (In reply to comment #4) > > Just a thought: could it be because the files change outside of the task ? I'm > > using git to manage the code and often, a file is changed outside of a task. > > Maybe the task gets confused when functions change location within a file, In > > that case it would be again a Mylin bug... > > Peter > > What do you mean by "change outside of the task"? Are the files modified by > another process (git)? In this case, neither CDT nor Mylyn can be blamed. > Out-of-sync resources will always cause issues with Eclipse. When resources > change outside Eclipse, you need to explicitely refresh them first. Yes of course. Forget my comment, it is not relevant to this bug. The bug I'm describing happens with a normal workflow, without changing the files from an external application. Sorry for the noise. Peter
Created attachment 120580 [details] A mini C++ project which causes the bug This project in combination with the new context I'm submitting causes the 'unresponsive-to-clicking' bug.
Created attachment 120581 [details] mylyn/context/zip
Importing the attached project on a fresh workspace with a fresh eclipse-cpp install, I don't have the bug anymore (platform is x86_64 instead of x86 though)... The original setup had many more plugins installed as well. So it is: A. a workspace problem OR B. a plugin conflict problem... I propose to close this bug until I can reliably reproduce it... Thanks for your attention though. Peter
