Community
Participate
Working Groups
Build ID: M20071023-1652 Steps To Reproduce: 1. Open a few *.c or *.h source files from Project Explorer. Choose files that are in different folders. 2. Click between the various files that are open. Project Explorer doesn't update to show where the currently selected file is in the file hierarchy. More information: This is an annoying problem when you F3 (Go to Declaration) and the IDE opens a *.h file that you aren't familiar with and don't know where it is in the project without doing a windows file search. The location would be obvious if the Project Explorer would update focus to whatever file is selected.
This works for me in general. Can you give more details in which case this does not work for you?
Created attachment 87860 [details] Screencap of Project Explorer not updating focus
Created attachment 87861 [details] Screencap of Project Explorer not updating focus
One of those 2 attachment posts can be deleted. It's a duplicate post. And in both posts, my comments didn't make it to the board so here they are: I'm working with the bundled CDT installation release which is based on Eclipse v3.3 because the v3.4 is not working well for me. This version, while deplete of some of the nicer features that have been implemented in v3.4 is more stable for me. Included is a screencapture showing the Project Explorer not updating.
You need to enable the "Link with editor" feature.
That took care of it! Until I knew to look for that feature, I didn't know it existed. I guess technically this bug can be closed, but the real bug is that this feature isn't on by default. Is there a good argument for keeping it disabled by default? I can't think of one.
(In reply to comment #6) > I can't think of one. Well... because some people find it annoying. I don't like how it causes the project tree to keep expanding and expanding as you navigate.
At my company, we have a tree-structure in our User Interface that's much the same and we got the same complaints from customers that they would get "lost" in the tree. So what we did was automatically relocate focus like normal. But auto-collapse all other folders so there's only one folder/path completely expanded at a time. This solved both problems of getting lost in the tree and not knowing where you are when you jump to other locations. Given this dialoge, it seems logical that the same thing could be implemented here as a feature request, not as a bug. Thoughts?
(In reply to comment #8) Sounds like a decent feature to me, you could open a feature request if you like. Also, I think the Mylyn CDT bridge effort is trying to address issues like these, see bug 162558.
Many of the things I've been writing up as bugs are more correctly called feature requests OR usability issues/concerns. At my company, we treat usability issues pretty much the same as a bug, but I can also understand the need to handle them as feature requests. So Where do I submit feature requests for things that are truly feature requests? I'd like to get the ideas somewhere where they can be kicked around and considered.
Just to set some expectations... this is very non-standard behaviour. You might get the Platform team to implement it as an optional feature, but I doubt it would ever become the default. Most of us would find it annoying because it's not the typical way an IDE works. And to reiterate, the Platform team handles the project explorer's behaviour. You'd have to take this up with them.
That makes sense. But to reiterate, is there a single repository for accepting/handling feature requests?
(In reply to comment #12) Bugzilla is used for feature requests, sorry I guess I confused you. I meant that you could open another bug asking for it as a new feature since this bug has been closed.
