| T O P I C R E V I E W |
| jlbooth318 |
Posted - Jul 05 2007 : 09:47:13 AM
It would be nice if the refactoring Rename dialog would order the file selections by the respective project to which the file(s) belong.
Alternatively, have the top level nodes of the checkbox tree show the project names to which the file(s) belong. This would make it easy to change the name of a class in a single project of a multiple project solution. |
| 4 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Jul 07 2007 : 08:09:49 AM
I have seen code where cpp files are included in more than one project inside a solution *sigh*
These were not low level library files, but fairly high level controls, but due to the "mess" the solution was in, someone decided it was easier to just drop the cpp file into two or three different projects than it was to put the code into a library project and use it that way.
This code base had nothing to do with VA in case you are wondering, it was at an old job, but this just adds another unpleasant edge case to consider.
Showing which project a file is in has come up before:
http://forum.wholetomato.com/forum/topic.asp?ARCHIVE=true&TOPIC_ID=3966
Since this was about the OFIW dialog the suggestion to show one project name, and then just "..." to indicate that there are more projects works well enough.
For rename it probably makes more sense to leave the project name blank, or replace it with something like "found in multiple projects" if this happens. This way the user knows that something odd is going on, and we avoid giving them a false sense of "security" about the rename operation.
Of course none of this helps with sl@sh's case of duplicate class names in the same project. |
| sl@sh |
Posted - Jul 06 2007 : 03:55:53 AM
Hmm, I'm a bit sceptical about this: if you have a multiple-project solution, then you are bound to have files (usually headers) that are shared between them. And if you want to keep your projects well apart, then likely these headers reside within a common include directory. Which means it won't be easy to automagically decide which project they belong to!
Regarding the suggested task of renaming a class within a project - this assumes a class name would always be unique within a project. Sadly you cannot make such an assumption to hold in all cases. As a matter of fact, you can easily create hundreds of different classes bearing the same name within a project, as long as the file names they are stored in are different. This would still compile as long as you take care only to include one of these class' declaration anywhere within your project. Of course, such cases should be rare, just wanted to point out an edge case that might make a certain job a tad more difficult to implement.  |
| jlbooth318 |
Posted - Jul 05 2007 : 10:09:45 AM
Yes, in our case the file paths do help identify the project.
Perhaps if there were a couple buttons at the top of the Rename dialog that can quickly select the scope of the rename operation. I had to rename a single class in a solution that has like 39 different projects. However the class name was found in several of the projects. This meant I had to sort through all of the references across the other 38 projects.
Of course, I could have opened the single project up in VS2003 and do the rename. But we have great tools like VAX to help with this sort of drudgery  !
|
| feline |
Posted - Jul 05 2007 : 09:53:33 AM
I rather like this idea, but what happens when a file belongs to more than one project at the same time?
Do the file paths give you a clue to the project the file belongs to? This will depend on how organised your code base is. |
|
|
