| T O P I C R E V I E W |
| V.Solo |
Posted - Sep 12 2006 : 8:40:17 PM
Can someone enlighten me as to how "Rename" refactoring works and what it's supposed to do?
"Rename" refactoring page of the online documentation states :
quote:
Rename changes the definition and all references, and declaration when programming in C/C++. Rename applies the change throughout your workspace.
"Well, great!", I said to myself and initiated a rename on a class name in my workspace. The "Rename" dialog showed up, listing lots of the instances of that class name showing up in the code (well, there are quite a few, so I can't really claim that all got listed, but what did get shown was enough for a nice start).
"Ok, I'm impressed...", I said to myself and hit the "Rename" button. All instances of that class name showing up in the file I had open (as top-most window) got renamed alright, but... It was all over kind of too fast... And sure enough, that single file I was working on was pretty much the only file that got changed (on subsequent tries it got worse - no files would be changed at all! see below).
Actually, additional testing turned up further problems.
For one thing, VAX gets most severely confused by the same files being included in several projects - it keeps listing them multiple times (thus, potentially allowing a checked checkbox and unchecked checkbox related to the same actual instance of symbol (but in different projects) to co-exist. Which is clearly wrong, IMO.
For another thing, if I double-click on an instance of symbol in "Rename" dialog list (leading to a different file being opened in the IDE) and then hit "Rename" button, I think nothing gets renamed at all (even though the IDE gets stuck in a very scary half-drawn state for a minute or so), certainly not in the top-most open file, which seems kind of wrong as well...
At that point I simply gave up on testing, since there was so much broken so as to obscure the stuff that may have worked right.
Is there something about the expression "throughout your workspace" that I'm missing? Am I reading the wrong documentation page? Am I missing some fine print hidden someplace at the bottom of the page? Are there some limitations to "Rename" refactoring that I'm not aware of?
Generally speaking, I find the "Rename" refactoring to be very useful. But in order to be very useful to me it really must be applied throughout the workspace. If I have to manually open hundreds of files to invoke such "rename", then I don't need VAX - MS' IDEs have supported "Search and Replace" for ages...
Lang : C++.
Other add-ins : Intel XDB Browser (inactive).
Sample code : er... sorry, I don't thinks so. But we're talking about a moderate ~220 KLOC, ~1K files workspace of ~100 projects.
VAX "About" info :
quote:
VA_X.dll file version 10.3.1534.0 built 2006.09.02
Licensed to:
VA X: [email protected] (X-user license) Support ends 2007.XX.XX
VAOpsWin.dll version 1.3.3.6
VATE.dll version 1.0.5.8
evc.exe version 4.0.1610.0
Devshl.dll version 4.0.1610.0
Devedit.pkg version 4.0.1610.0
Comctl32.dll version 5.82.2900.2180
Windows XP 5.1 Build 2600 Service Pack 2
|
| 13 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Oct 06 2006 : 7:54:23 PM
Case 2438 is fixed in 1538. |
| sean |
Posted - Sep 17 2006 : 8:58:07 PM
quote:
Originally posted by V.Solo
I wonder why wouldn't VAX get notified or fail parsing the project... I'm working with the same workspace 90% of the time and most changes are changes to files, not projects. It's just that sometimes my OFIW is empty... What factors do normally contribute to either of problems you mentioned?
Well it's not normal - but for example we had a case in VS where VA did not parse projects that were built for the Intel compiler due to it using a different file extension. It wasn't clear to me that the OFIW problem has been intermittent. If the OFIW problems are intermittent and only occur in evc4 (or vc5/6), then the problem might be bug 2438. Due to that bug, files are removed from the VA db after a project in a multi-project workspace has been modified (and the "watch for externally modified files..." VA option is set (VA Options|Text Editor|C/C++). Until 2438 is fixed (currently on track for build 1536), you may want to disable the "watch for externally modified files..." to see if behavior improves.
quote:
As a side note, while I'm testing 1534, the "rename" feature keeps consistently failing on large-scale renames (I'm talking about both lack of actual source files changes and presence of multiple entries for each file that should be affected in the list of candidates) while both OFIW and FSIW work just fine. So I don't really think those two kinds of failures are connected, at least not directly.
maybe - depends on the type of failure. No files in OFIW would mean that rename would only find instances in the file that was open when the command was invoked and in header files that it includes, etc. Doesn't explain failures when the OFIW reflects correct state though.
|
| V.Solo |
Posted - Sep 17 2006 : 7:28:53 PM
sean :
quote:
If your OFIW list is empty, that indicates that either VA did not get notification that a solution/workspace was opened or was unable to properly parse the project. Needles to say, this will adversely affect many features.
I wonder why wouldn't VAX get notified or fail parsing the project... I'm working with the same workspace 90% of the time and most changes are changes to files, not projects. It's just that sometimes my OFIW is empty... What factors do normally contribute to either of problems you mentioned?
As a side note, while I'm testing 1534, the "rename" feature keeps consistently failing on large-scale renames (I'm talking about both lack of actual source files changes and presence of multiple entries for each file that should be affected in the list of candidates) while both OFIW and FSIW work just fine. So I don't really think those two kinds of failures are connected, at least not directly. |
| sean |
Posted - Sep 17 2006 : 7:06:54 PM
If your OFIW list is empty, that indicates that either VA did not get notification that a solution/workspace was opened or was unable to properly parse the project. Needles to say, this will adversely affect many features.
If you continue to experience this problem please send in logs per the instructions at:
http://www.wholetomato.com/support/faq.asp#log
|
| V.Solo |
Posted - Sep 17 2006 : 3:26:28 PM
feline :
quote:
this is totally different to the free form world of C++, where people do not even agree if the comment in a cpp file should go above or below the function name, let alone the format of the comments.
Well, WT could always standartize on Doxygen-style comments...  (In case it wasn't obvious from the wink, that remark follows from both me personally and my company using Doxygen)
quote:
V.Solo i have just set-up the following test project.
using EVC 4, VA 1535 running on win2k i have created a new, standard, WCE Application, accepting all of the defaults.
i then added two new projects, both of type "WCE MFC AppWizard (dll)" to the workspace, again accepting all of the defaults. <snip>
I've done pretty much the same, except on the same rig as listed in my original post. And yes, everything worked as expected. Well, almost... Any and all attempts to "rename", use OFIW, or anything else complicated failed miserably : OFIW was empty no matter what, "rename" renamed only inside the currently active file, etc. Saving workspace, closing eVC4, reopening eVC4, reopening workspace and THEN using "rename" worked fine (no dupes, BTW!), OFIW showed files alright, etc. BTW, this isn't the first machine, workspace or VAX version I'm experiencing such behavior with - sometimes VAX simply seems to have a bad hair day, or something.
quote:
this should be a valid, tiny, test of your situation.
This is indeed a tiny, but, apparently invalid test of my situation. Because right after I was done reproducing this test case (and observing it work properly), I closed this workspace, reopened our product's workspace and observed all the problems listed in my original post all anew. Closing that workspace, reopening test case inspired by your post and doing some more renames worked fine.
quote:
if you look in OFIW are the files for the class you wanted to rename listed more than once?
Nope. If and when OFIW works at all (see above about VAX's bad hair days) it usually works top notch, including with our product's worspace.
quote:
if you do more limited rename's, say on a local variable, or a private class member function, do they work successfully?
Local var - yeah, no problems.
Private member func - no problem.
quote:
my tests seem to prove that duplicate files on there own are not a problem, but something has caused the problems you are seeing.
Well, there's also the matter of scaling to be considered...  A thousand files packed into a hundred production-grade projects in a single workspace is a bit tougher feat than 10 files in 3 projects... But then again, what the heck would I know about VAX's internals...
Anyhow, is there anything else you'd like me to try? |
| feline |
Posted - Sep 17 2006 : 1:19:42 PM
the easy one first, from my experience with C#, the IDE wants you to use XML format comments, so the comments can be considered to be in a single, fixed format, and the IDE knows what function a comment is linked to.
this is totally different to the free form world of C++, where people do not even agree if the comment in a cpp file should go above or below the function name, let alone the format of the comments.
personally i am very wary of any statement that starts "but VS2005 can do it in C#"  this does not automatically map to C++
V.Solo i have just set-up the following test project.
using EVC 4, VA 1535 running on win2k i have created a new, standard, WCE Application, accepting all of the defaults.
i then added two new projects, both of type "WCE MFC AppWizard (dll)" to the workspace, again accepting all of the defaults.
this gives me a workspace with 3 projects.
i then copied over a cpp and .h pair, for one of my classes, and placed the files into the base directory for this project.
both files were then added to each project, so the workspace contains 3 references to the cpp file and 3 references to the .h file, one per project.
this should be a valid, tiny, test of your situation.
when i told VA to rename the class i added it only found two files. so the duplicate file's was only listed once each.
if you look in OFIW are the files for the class you wanted to rename listed more than once?
if you do more limited rename's, say on a local variable, or a private class member function, do they work successfully?
my tests seem to prove that duplicate files on there own are not a problem, but something has caused the problems you are seeing. |
| schoenherr |
Posted - Sep 14 2006 : 01:04:07 AM
regarding the rename in comments:
VS2005 has check boxes for
1.) Preview reference changes
2.) Search in comments
3.) Search in Strings (not mentioned in this thread until now) |
| V.Solo |
Posted - Sep 13 2006 : 07:44:48 AM
rhummer :
quote:
Would you have any odd setting that would prevent VA X from modifying the files? IE: Not allowing the modification of read-only files.
Not that I'm aware of : all files are writable and have necessary access permissions set. Besides, that wouldn't explain VAX listing files included in multiple projects over and over again.
quote:
Are all the files you wish to have Rename run on added to you're projects solutions?
Affirmative. But, as I mentioned, even in VS2005 - in which VAX worked way better - it skipped my *.inl files.
quote:
What IDE are you using exactly?
Sorry, I thought it was obvious from my "About" info in the original post : eVC4. I'd also like to test it with VC6, which is very close to eVC4, but the machine I'm test-driving 1534 on doesn't have one. I'm a bit wary of upgrading my production machine (which has VC6) to 1534, at least for now. Maybe later, when I have more confidence in it (or some patches flow in).
quote:
IMO, updating the comments is a whole bag of worms, what defines a comment for that method. Does it always lie above the method in the header file, <snip>
Well, in case such as this, i.e. renaming a class, I don't want any heuristics applied to selecting what comments to update, I want all of instances where the old class name was mentioned to be changed, throughout the workspace (though I still want an opportunity to un-tick checkboxes if I deem the renames in comments inappropriate).
IMO, for the most part, the issue would be not "what defines a comment", but rather "is that comment talking about the same class/method/type/whatever 'FOO' as the one I'm trying to rename". But I'd still prefer to have to make decisions about what to include/exclude from "rename"/"rename in comments" action in a singe centralized location, using convenient checkboxes, with popup contexts and ability to jump to specific instances, rather than the manual "Search and Replace" story on hundreds of files.
Renames of func/method arguments and auto vars probably would suffer from "what defines a comment" thing, but I think it could be solved by a checkbox or two somewhere in VAX settings or the dialog itself (i.e. let the user decide what to consider a "func/method comment", to what scope to limit the action : file/module/project/workspace, etc).
Yeah, sure, renames in comments are not a one-liner. But hey, if everything in life was a one-liner, then we wouldn't get paid the salaries that we do get paid and VAX would have cost $5 (can you imagine paying more for a hundred lines of code? ) |
| rhummer |
Posted - Sep 13 2006 : 01:12:06 AM
jpizzi, the refactoring exists within C# projects only, as far as I know, they might exist in VB project but I don't know.
IMO, updating the comments is a whole bag of worms, what defines a comment for that method. Does it always lie above the method in the header file, thats all I can think of being this tired..I got more jsut not on a half a sleep mind ;) |
| jpizzi |
Posted - Sep 13 2006 : 01:01:01 AM
I assume you mean good comment, not goo comment
I agree that it would be nice to have the comments updated. Is that the good comment you are speaking of?
What refactoring was added in VS2005? I looked, and could not find any. Surely, you are not talking about find/replace, are you? I couldn't even find a preview window for that. |
| schoenherr |
Posted - Sep 13 2006 : 12:47:39 AM
V.Solo made a goo comment about refactoring/rename in comments!
i think it worth to rework this feature especially, because the VS2005 build in refactoring has this feature in an impressive way (they even have a preview window) |
| rhummer |
Posted - Sep 12 2006 : 11:35:11 PM
I have been using the Rename refactoring option since the early private betas and the only time I haven't seen it work is on some STL containers which were fixed before the release.
I've just ran Rename on a local project that touched many files (1671 references to be exact), as it's a string class used all over. It worked perfect for me, minus headers that VA X doesn't know about as they are not in the project or my search directories. ;)
Would you have any odd setting that would prevent VA X from modifying the files? IE: Not allowing the modification of read-only files.
Are all the files you wish to have Rename run on added to you're projects solutions?
What IDE are you using exactly? |
| V.Solo |
Posted - Sep 12 2006 : 9:55:40 PM
<after some more fiddling>
Well, the good news is that in VS2005 "Rename" does remarkedly better. It didn't get confused by the same files being included in different projects, and it replaced almost all instances if that class name throughout the project. That's too bad - we're not using VS2005 around here.
VAX did refuse to rename inside *.inl files, despite VS2005 recognizing them properly. Item 5 of FAQ wasn't particularly helpful here because my VANet8 node has no ExtHeader/ExtSource keys at all (though my VACE4 node has Ext* keys aplenty and is generally way more populated than VANet8 which has barely 6 keys). What gives?
And, of course, the comments were left untouched. That's a major concern, you know; documentation that is out of date isn't worth the electrons it's delivered with. Was leaving comments out of renaming a result of a technical limitation or a deliberate design decision? Manual "Search and Replace" in a hundred of files is a bummer regardless of whether you're replacing pieces of code or pieces of comments... |
|
|
