| Author |
 Topic  |
|
|
mwh
Junior Member
14 Posts |
 Posted - Dec 04 2013 : 02:59:34 AM
|
When I use the VA Snippet "Refactor Create Implementation" for a method in a derived class, the implementation is created with the scope identifier of the base class:
A.h:
class A {};
B.h:
class B : public A
{
public:
void foo(); // (1)
};
Refactor Create Implementation on (1) creates in B.cpp:
void A::foo()
{
}
instead of void B::foo() {}
This behavior appears only in some solutions/projects, in others the behavior is correct. Now I am wondering if it is some project and/or VA setting that causes this behavior. Any idea? |
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Dec 04 2013 : 7:09:17 PM
|
This is not supposed to happen, and since it is only effecting some code this suggests something is confusing our parser in these situations.
In one of the problem places, can you please place the caret into the function name, in the declaration, and look at the VA Context field, normally at the top of the editor, on the left hand side. It should show:
B.foo
in your example. So the current class name, and function name. If this is wrong then that will be a direct clue.
Can you also look at VA Outline and the Alt-M list for the header file where you have these problems, and see if you see anything that looks odd or wrong? If our parser is confused in the header file you may well see signs here. |
zen is the art of being at one with the two'ness |
 |
|
|
mwh
Junior Member
14 Posts |
Posted - Dec 05 2013 : 02:08:31 AM
|
Hello feline,
I did as you suggested and the VA context field showed indeed A.foo
VA Outline looks ok, foo is nested into the method tree for class B and in the method list (Alt-M) the method appears correctly with B::foo
Perhaps I should also mention that A and B are in the same (not global) namespace, perhaps that information can also contribute to a solution. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Dec 09 2013 : 3:04:58 PM
|
Thank you for the update. Its reassuring, if unhelpful that the VA context field is showing the wrong class, so we have something a little easier to check. At least this way its not simply that Create Implementation is doing something totally random.
Can you please move the caret through all of the class members in class B in the header file please. Does the VA context field show class A for all of them? Or does it show the correct parent class for some of the members and the wrong parent class for other members?
If something "simple" like this happens:
class B : public A
{
public:
void memberOne(); // correct context field
COMPLEX_MACRO;
void memberTwo(); // wrong context field
};
then it would suggest that the macro, or possibly inline function declaration, etc, is where the problem starts. I am surprised that VA Outline and the Alt-m list both look correct though.
This suggests you will see the wrong class for every class member in the context field, suggesting its something above the class in this file, or something about the class declaration its self. Do you use the "class" keyword directly? Or is it wrapped in a macro of some form? I am still looking for a clue as to what is going on here. |
zen is the art of being at one with the two'ness |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Dec 10 2013 : 01:30:49 AM
|
I placed the caret into every class member of class B and for every member the VA context field said "A::<class member>", even for fields.
After you mentioned macros, I did some more research, because we are using Qt in our application and I thought that this odd behaviour appears only in classes that are derived from Qt objects (and hence include the Q_OBJECT macro). What I found was:
- Class B in my example is derived from a Qt class and contains the Q_OBJECT macro.
- For all other Qt derived classes in this project (I checked a few only though) the VA context field behavior is also wrong.
- Another class C in the same project does not derive from a Qt class and the VA context behaviour is ok and as expected.
So perhaps Qt is the culprit here, however, two facts contradict this assumption:
1. When I let class B derive from something else (non Qt-ish) and remove the Q_OBJECT macro, the odd behaviour of the VA context field remains.
2. In another Qt project, this odd behavior does not appear for Qt derived classes and the VA context field displays correct values.
I hope that my research helps you a bit in finding the problem. |
Edited by - mwh on Dec 10 2013 01:32:45 AM |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Dec 10 2013 : 01:41:25 AM
|
Some more information for you. :-)
I checked the behaviour at my colleague's computer with the same project and on his computer the behaviour is correct for all classes. So I checked the VAX version numbers and he still has the 10.7.1906.0 while I already have the 10.8.2001.0. We both have VS2008 with all service packs and updates.
Edit:
The version does not appear to be the problem. I updated both computers to 10.8.2007.0, no change. On his computer all is ok, on my computer the problem remains.
I also deleted the complete project folder from my harddisk and copied it back from our source control - problem remains. |
Edited by - mwh on Dec 10 2013 03:29:16 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Dec 10 2013 : 4:18:09 PM
|
Thank you for your checking, since this is machine specific, and quite a few of our customers use Qt, we can fairly safely assume that deriving from a Qt class is not the trigger on its own.
Can you please try pressing the button:
VA Options -> Performance -> Rebuild symbol databases
and restarting your IDE and reloading your main solution. Telling VA to reparse all of your code will take a few minutes, but hopefully not to many minutes.
Can you please go to:
VA Options -> System Info -> Copy Info
and paste the details (from the clipboard) into your reply. This will give us the basic information about your setup. I am mainly interested in your stable include directories, and it would be interesting to know if they are the same or different to your colleague's. If you have different stable include directories, or different versions of Qt this might be a clue. |
zen is the art of being at one with the two'ness |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Dec 11 2013 : 01:39:00 AM
|
Rebuilding the symbol databases had no effect, the wrong behaviour remains.
Here is my output from "Copy Info":
License: [email protected] (20-user license) Support ends 2014.02.03
VA_X.dll file version 10.8.2007.0 built 2013.11.15
DevEnv.exe version 9.0.30729.1 Enterprise
msenv.dll version 9.0.30729.4108
Font: Consolas 15 (pixels)
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
8 processors (x86-64, WOW64)
Language info: 1252, 0x407
Platform: Win32
Stable Includes:
D:\\Programme\\Visual Leak Detector\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\crt\\src;
And here the output from my colleague:
VA_X.dll file version 10.7.1906.0 built 2012.05.10
Licensed to:
VA X: [email protected] (20-user license) Support ends 2014.02.03
DevEnv.exe version 9.0.30729.1 Enterprise
msenv.dll version 9.0.30729.1
Font: Courier New 13(Pixels)
Comctl32.dll version 6.10.7601.17514
Windows 7 6.1 Build 7601 Service Pack 1
12 processors (x86-64;
WOW64)
Language info: 1252, 0x407
Platform: Win32
Stable Includes:
C:\\Program Files (x86)\\Visual Leak Detector\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\include;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\include;
Other Includes:
Stable Source Directories:
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfc;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\mfcm;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\atlmfc\\src\\atl;
C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\crt\\src;
We are both using the same Qt version (4.8.0). |
Edited by - mwh on Dec 11 2013 01:39:54 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19137 Posts |
Posted - Dec 18 2013 : 10:36:00 PM
|
Sorry for the slow reply. As you probably realise, there are no obvious clues here.
Can you make sure the problem header file is closed, then enable VA logging, and then open the problem header file, and trigger:
VAssistX -> Tools -> Reparse Current File
and place the caret into the class name, then a couple of the class members, letting the VA context and definition fields update in each case before moving on.
Can you then please email us the log files, hopefully this will offer some clues as to what is going on. This is explained in this FAQ entry:
http://docs.wholetomato.com?W305
Do you have any IDE add-in's installed?
IDE tools menu -> Add-in Manager -> list of available add-ins
|
zen is the art of being at one with the two'ness |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Jan 20 2014 : 02:55:53 AM
|
Now I have to apologize for the late reply, but for some odd reason I did not get notified about your reply.
I enabled the logging and will send the va.log to you.
However, in the meantime I noticed something that might be helpful. The class for which VA shows this strange behavior is exported. I have an export macro that is defined in a header file, which is then included into the class' header file. The macro is simple and goes:
#undef MY_EXPORT
#ifdef MY_LIB
#define MY_EXPORT __declspec(dllexport)
#else
#define MY_EXPORT __declspec(dllimport)
#endif
The class is defined as
class MY_EXPORT B : public A {...};
When I remove the macro in the class definition, everything works fine, when I add it again, VA returns to the strange behavior.
I'm sorry that I did not mention this earlier, but I got so used to this macro that I never though it might be a problem. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jan 23 2014 : 5:51:33 PM
|
I wasn't able to reproduce the problem, but have an idea for a workaround. Create a new file, named va_stdafx.h next to your solution and put the following lines to it:
#define MY_EXPORT
// make sure you have new line after the macro
Now rebuild the symbol databases. Does it help? |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Jan 24 2014 : 02:03:19 AM
|
Yes, that did help indeed! :-) VA behaves now as expected.
I will keep that workaround for now, but since a whole team works on that solution and only "my" VA shows this strange behaviour, I'd rather not keep that header file forever. ;-) So I hope that the fact that the workaround works can help you find a final solution for the problem.
Thank you. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Jan 24 2014 : 3:11:41 PM
|
| It's possible that you have a local setting or difference in your environment that causes this. One thing that might help is to create a new Windows user account to see if it makes any difference. |
Edited by - accord on Jan 24 2014 3:12:59 PM |
|
|
|
mwh
Junior Member
14 Posts |
Posted - Feb 13 2014 : 01:58:03 AM
|
I just wanted to let you know that in the meantime it was necessary to setup my computer completely new. After installing VS2008 and VA again, the problem did not show up again. So at the moment, it is no longer reproducable anymore. However, I am really still curious what in the end caused this wrong behaviour. If you ever find something out, please let me know.
Thanks for your efforts in solving this problem. |
|
|
| |
Topic |
|
Refactor Create Implementation
