T O P I C R E V I E W |
hensz |
Posted - May 22 2007 : 07:52:08 AM Hi!
I created a class for a Unit Test (CppUnit): class CTestXXX : public CppUnit::TestFixture, added a test suite declaration including some tests. Now I added some functions: void testOne(); void testTwo();
When I open the refactoring menu on the first function VA tells me that "Refactoring [is] not available on symbol". Refactoring for the second function works.
I changed the order of the two functions: void testTwo(); void testOne();
Now refactoring works for function testOne, but not anymore for testTwo.
btw: It would be great if the refactoring menu would appear when the cursor is directly before or after a word, not only when it's inside a word.
Best regards, hensz |
9 L A T E S T R E P L I E S (Newest First) |
support |
Posted - Jan 31 2010 : 1:28:33 PM case=6820 is fixed in build 1810 |
feline |
Posted - May 29 2007 : 07:43:25 AM I assume you have assigned a keyboard shortcut to "VAssistX.RefactorContextMenu", if so then I am seeing the same effect. I have put in a feature request for this:
case=6820 |
hensz |
Posted - May 29 2007 : 03:16:05 AM Ok, I modified the StdAfx.h and rebuilt the symbol database. Now refactoring seems to work fine. Thank you for the help!
One final thing: What about the feature request I mentioned in my first posting: quote: It would be great if the refactoring menu would appear when the cursor is directly before or after a word, not only when it's inside a word.
This would help refactoring the code easier, since after one refactoring function call the cursor is positioned before the current symbol. When I move down to the next function I must also move the cursor one step to the right to refactor again.
Best regards, hensz |
feline |
Posted - May 26 2007 : 2:09:40 PM I have tried adding these #define's to my test file, and it is not making any difference, refactoring is still offered as normal on all of the functions I am checking.
Can you try the following experiment please, edit VA's "StdAfx.h" file as explained in this FAQ entry:
http://docs.wholetomato.com?W302
and add the entries:
#define DATA_ACCESS_NAMESPACE_HEADER #define DATA_ACCESS_NAMESPACE_FOOTER #define DATA_ACCESS_NAMESPACE
at the bottom. This file is used to help VA's parser with difficult code, and can be used to work around odd effects. After modifying this file you need to rebuild the VA symbol database for the changes to take effect:
VA Options -> Performance -> General -> Rebuild symbol databases
This should make these #define's invisible to VA, so if they are causing the problem for you this should fix the problem. |
hensz |
Posted - May 25 2007 : 04:31:50 AM Hi! I'm using version 10.3.1555.0 built 2007.04.26. I turned on the 'italic' option, now the macros are shown in italic (and look very ugly), but the refactoring still isn't working. With and without this option the #define is shown in the VA definition field.
One difference could be that I'm using namespaces. I have three defines:
#define DATA_ACCESS_NAMESPACE_HEADER namespace my_company { namespace my_lib {
#define DATA_ACCESS_NAMESPACE_FOOTER } }
#define DATA_ACCESS_NAMESPACE using namespace my_company::my_lib;
In the header each class is surrounded by the pair DATA_ACCESS_NAMESPACE_HEADER and DATA_ACCESS_NAMESPACE_FOOTER, in the source file after all includes I've added DATA_ACCESS_NAMESPACE. Perhaps this hexes VA?
I just made a quick test. I added a unit test without the namespace defines. Now refactoring works fine for all functions.
I hope you can reproduce the issue with this information. |
feline |
Posted - May 24 2007 : 1:39:59 PM Which version of VA are you using? Have you turned on "VA Options -> Advanced -> Fonts and Colors -> Stable symbols in Italic" ?
I have opened a test project here that uses Cpp Unit and I am checking out a header file that has a block of macro's of the form:
class testThings : public CppUnit::TestFixture { CPPUNIT_TEST_SUITE(testThings); CPPUNIT_TEST(func1); CPPUNIT_TEST(func2); CPPUNIT_TEST(func3); CPPUNIT_TEST_SUITE_END();
// class functions here }
the CppUnit macro's are all shown in italic, when I place the caret into CPPUNIT_TEST a #define is shown in the VA definition field, and there are no problems with refactoring, it is offered on all of the class functions I have checked.
I am wondering why my results seem so different to yours. |
hensz |
Posted - May 24 2007 : 03:49:04 AM By the way, I posted some screenshots.
I created a unit test class, and refactoring looks like this:
Everything looks fine, except the refactoring menu.
Now take a look at refactoring the last function:
As you can see the closing bracket is red.
After that I looked up the definition of the CppUnit macros. The macros contain some opening and closing brackets. I suppose that this is a problem for VAssist.
After that I marked a function name and tried refactoring. This looks funny:
Extracting a method by extracting it as method doesn't make sense.
After all that tests I moved the macros below the functions. Now everything works fine. Nevertheless it would be fine if VA would recognize the macros correctly.
Best regards, hensz |
hensz |
Posted - May 23 2007 : 05:38:53 AM The problematic function is not underlined, but there are macros above. The code lokks like this:
CPPUNIT_TEST_SUITE( CMyUnitTest);
CPPUNIT_TEST( testOne );
CPPUNIT_TEST( testTwo );
CPPUNIT_TEST_SUITE_END();
void setUp();
void tearDown();
void testOne ();
void testTwo ();
I just checked again: Refactoring is not available for setUp, tearDown and testOne, but it's available for testTwo (of course I cannot reproduce it right now... narf!). When I exchange testOne and testTwo refactoring is (nearly always, just not right now) available for the second of those.
The macros as well as the functions setUp and tearDown are part of CppUnit. I set up the unit test framework like in the example of CppUnit (the Money example).
I hope this helps to reproduce the issue. Otherwise just contact me again.
Best regards, hensz |
feline |
Posted - May 22 2007 : 1:28:26 PM Is the "problem" function underlined as a mistyped symbol?
My first guess, there is something above this "problem" function that is the real cause of the problem, perhaps a macro. Can you try commenting out / deleting the items above to try and produce a small code sample that reproduces this problem that you could post? |