T O P I C R E V I E W |
Frunobulax |
Posted - Jun 26 2008 : 04:24:36 AM [VS2005/C++] Hi,
if I do refactor/rename on an identifier in resource.h, renaming will be done only in .cpp and .h files but not in the .rc files that are part of the solution.
Shouldn't all text files in the solution be checked? We have .dox files for our doxygen summaries that should be changed too.
Regards, tv
|
7 L A T E S T R E P L I E S (Newest First) |
feline |
Posted - Jul 09 2008 : 7:31:17 PM I have put in a feature request for rename to search inside .rc files:
case=18366
Searching inside other "unknown" file types is a different question. |
znakeeye |
Posted - Jul 08 2008 : 11:52:27 AM This is bugging me too. I really don't see why entries in resource.h are renamed, but not in its corresponding rc-file. In VC++, they are indeed coupled. |
feline |
Posted - Jun 30 2008 : 5:09:07 PM There are two separate points at work here.
RC files first. VA has some knowledge of these, but I am not sure how much it knows about them. Searching inside of these files sounds reasonable to me.
"other" files. These may or may not be plain text. They may or may not be safe to simply update. I am wary about this, due to possible edge cases. |
Frunobulax |
Posted - Jun 30 2008 : 3:50:07 PM Well, simple search and replace will do any renaming if you are careful :-)
Still, if you rename IDS_COPY to IDS_FOO then IDS_COPY_ALL will become IDS_FOO_ALL. And of course you may have a number of different resource files.
The question is really "why should resources be excluded"? They use constants defined in C++ headers and VAX finds the symbols used in resources, so VAX "knows" about resources. To me it is very natural that renaming should be extended to them.
tv
|
feline |
Posted - Jun 30 2008 : 3:39:58 PM Binary files, my first answer is ICO files. I am used to seeing these, and other graphic files, as part of the solution.
I would definitely expect DLL files to be binary. I am not sure to what degree they are part of the solution, but in C# solutions you start getting into dependencies, and I am used to seeing people import DLL's and related files.
A more interesting example is Qt, where there is an IDE plugin, and you start getting auto generated files from its code designer. These files are not designed to be manually edited, they are only supposed to be edited via the relevant tool. I suspect most of the generated files are going to be plain text, but people add all sorts.
Experience indicates if it can be made to compile, some of our users are doing it
Personally I know very little about RC files. Can you explain why a simple search and replace is not going to work? |
Frunobulax |
Posted - Jun 27 2008 : 5:04:58 PM Well, resources belong to the source code, and if I refactor the constant in the header then the code becomes incorrect if the renaming is not done in the resource. And no, a simple "find and replace" may not do the trick :-)
I see your point about binaries, but which binary files may be actually part of the project/solution? And there's always that checkbox where one can decide in which files the renaming should be done. But if I have a separate documentation then I most definately want to have changes reflected in the documentation.
Regards, tv
|
feline |
Posted - Jun 26 2008 : 5:25:07 PM If VA looked at RC or other text files then it would need to be a very simple "find and replace" without any intelligence. Would this be enough?
The items to replace would still be listed in the rename dialog for you to confirm, but you might get a lot of references, depending on the symbol you are renaming.
Things like "dox" files bother me, simply because what if VA opens an XML or other structured file? Running the rename across a "random" file could do nasty things to it. Also I am concerned about binary vs text files. RC files are a standard feature, but as soon as you say "open all files" we are going to start running into binary or semi-binary files sooner or later.
If such files and all the references inside of them were unticked by default then this should be relatively safe. |