| Author |
 Topic  |
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
 Posted - Aug 25 2012 : 10:08:43 PM
|
pwc, have you seen this problem in previous builds of VA, or is this a new problem?
Is there any pattern to this problem? Does it effect all files and symbols, or only some?
pthiben, can you try coping the problem files into a new default test solution and see if you can reproduce the problem there? I am wondering if the problem is file or solution specific, this should tell us. |
zen is the art of being at one with the two'ness |
 |
|
|
vjtech
New Member
4 Posts |
Posted - Aug 27 2012 : 04:47:25 AM
|
Tried another solution sent me by support team.
It solved my case completely!
Thanks for great help! |
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Aug 27 2012 : 2:05:23 PM
|
Excellent news, thank you for the update  |
zen is the art of being at one with the two'ness |
|
|
|
pthiben
New Member
7 Posts |
Posted - Aug 27 2012 : 2:49:07 PM
|
I copied the problematic file to a new sln and added include paths so the headers could be found: the problem is gone.
I guess the problem is on the solution side this time, but I haven't found a narrower project that I could post here yet.
Hope this helps
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Aug 30 2012 : 09:59:16 AM
|
In the problem solution is the header file in the same directory as the cpp file? I assume not, from your comments here.
In the problem solution, if you sit in either the header or .cpp file and press Alt-O what happens? I am wondering if the settings for include file locations could be a factor here. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Sep 13 2012 : 2:16:34 PM
|
| The regression was case=68625 and is fixed in build 1916 |
|
|
|
pthiben
New Member
7 Posts |
Posted - Sep 13 2012 : 5:20:48 PM
|
quote:
Originally posted by feline
In the problem solution is the header file in the same directory as the cpp file? I assume not, from your comments here.
In the problem solution, if you sit in either the header or .cpp file and press Alt-O what happens? I am wondering if the settings for include file locations could be a factor here.
Hi,
Sorry for the late reply. The source and header are located in the same directory, so Alt-O works.
I tried to add the vcprojx into a brand new sln and it's working. I presume the issue comes from the solution, but I still haven't nailed down what the differences are. I can't afford to move my projects to that new blank solution unfortunately =/
FWIW, we have projects with unity builds, ie projects with a few CPP files including multiple CPP files from other projects to speed up compilation times. Adding the Unity build project to the new sln doesn't break the Goto.
I installed 1916 but it doesn't solve the issue.
Thanks
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Sep 13 2012 : 6:02:33 PM
|
With VA 1916 installed can you please try turning Off:
VA Options -> Projects -> File Handling -> Restrict Goto (alt+g) results to active project
and see if this makes any difference? |
zen is the art of being at one with the two'ness |
|
|
|
pthiben
New Member
7 Posts |
Posted - Sep 14 2012 : 09:28:36 AM
|
quote:
Originally posted by feline
With VA 1916 installed can you please try turning Off:
VA Options -> Projects -> File Handling -> Restrict Goto (alt+g) results to active project
and see if this makes any difference?
No it doesn't, unfortunately.
FWIW, I believe the issue is on the solution side. Unfortunately, our code base is quite complex, and getting a simple repro is pretty hard
|
|
|
|
feline
Whole Tomato Software
United Kingdom
18749 Posts |
Posted - Sep 14 2012 : 7:38:41 PM
|
In your main solution can you please comment out the namespace macros, both in the .h and the .cpp file, save both files, and reload the solution. This will ensure that VA has caught up with the changes.
Now that the code is all in the global namespace, does Alt-g work? I am wondering if the problem is related to how the namespace macros are defined somewhere in the solution. |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Oct 29 2012 : 11:07:46 AM
|
| case=68625 fixes Goto for implementations that follow certain macro-generated methods, and is available in build 1918 |
|
|
|
GregDude
Senior Member
30 Posts |
Posted - Apr 22 2013 : 7:06:40 PM
|
I'm experiencing this issue again with v10.7.1929.0 build 2013.02.22.
ALT-G jumps to header declaration, but not to .cpp definition. Or from call, does not show the drop down with .cpp,.h or more options.
The behavior is inconsistent across the whole code base... It does work for some symbols.
Rebuilding database does not improve.
The issue seems to have reoccurred fairly recently as I use the feature all the time as it is most useful. I'm reporting back now as the problem has not gone away for the last week and I'm tiring of it. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 23 2013 : 09:36:31 AM
|
Can you please find a method where it fails?
1. Please move the caret over the implementation's name and paste the content of the navigation bar here.
2. Please now move the caret over the name of the method at the declaration as well, and paste the navigation bar's content here.
The navigation bar is above the editor, on the left, this is what lists the methods in a file, when pressing alt+m, but normally it just shows the context of symbols, and you can access the string if you click into the editbox.
I am wondering whether a context problem plays a role here, e.g. does VA recognise which namespace and/or class is both the implementation and declaration is in? The context and even the name should be the same, so the navigation bar should show the same string over both the implementation and the declaration of the same method. |
|
|
|
GregDude
Senior Member
30 Posts |
Posted - Apr 23 2013 : 5:52:40 PM
|
Here's and example of where it fails:
1) NAMESPACE_CN.FileDevice.RemoveSearchPath
2) int RemoveSearchPath(int a_level, const char* a_pathPrefix, const char* a_fileTypes)
Note that the 'NAMESPACE_CN' is a #define which resolves to 'cn'.
I notice poor behavior with class member functions wrapped in #defined namespaces.
Classes inside namespaces not #defined seem fine.
Non-member functions inside #defined namespaces also seem fine.
Just discovered something else...
The .h file wraps classes in namespaces like:
BEGIN_NAMESPACE_CN (#defined as 'namespace NAMESPACE_CN {' )
END_NAMESPACE_CN ( #defined as '}' )
while the .cpp file just uses
USING_NAMESPACE_CN (#defined as 'using namespace NAMESPACE_CN;' }
(Note, '#define NAMESPACE_CN cn' defined before these in shared header.)
However, if I change the .cpp file and wrap with Begin, End instead of Using. Alt-G seems to work correctly.
Although that may be a workaround, I believe it is quite valid C++ to not require 'namespace X { }' around implementation when 'using namespace X' sets the context for both function use and function definition. |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 24 2013 : 06:57:04 AM
|
2) It is the definition field (on the right) rather than the context field (on the left). I would need the left side for both the implementation and declaration.
Can you please post the source of NAMESPACE_CN here? So I can see what the problem might be or can try reproducing the problem.
Regarding the "using namespace" directive via macro: I was able to reproduce the problem and I have put in a bug report for this:
case=73855 |
Edited by - accord on Apr 24 2013 06:58:07 AM |
|
|
|
GregDude
Senior Member
30 Posts |
Posted - Apr 24 2013 : 4:52:37 PM
|
I can confirm that the #define namespace helpers are not related to the issue. I can reproduce this by replacing all macros with their defined text.
It is all caused by the 'using namespace'.
This issue has probably not occurred recently, instead I was just likely working on different areas of legacy code which use different namespace patterns.
To answer your question anyway, as above, the #define code is
#define NAMESPACE_CN cn
#define BEGIN_NAMESPACE_CN namespace NAMESPACE_CN {
#define END_NAMESPACE_CN }
#define USING_NAMESPACE_CN using namespace NAMESPACE_CN;
Thank you. |
Edited by - GregDude on Apr 24 2013 4:55:12 PM |
|
|
|
accord
Whole Tomato Software
United Kingdom
3287 Posts |
Posted - Apr 26 2013 : 3:54:36 PM
|
quote:
I can confirm that the #define namespace helpers are not related to the issue.
Yes, I can confirm that. You will need to turn on recursive macro parsing, however:
http://docs.wholetomato.com?W363 |
|
|
|
GregDude
Senior Member
30 Posts |
Posted - Apr 26 2013 : 5:28:16 PM
|
quote:
Originally posted by accord
[quote]...You will need to turn on recursive macro parsing, however:
http://docs.wholetomato.com?W363
Thanks. I guess that is why I see NAMESPACE_CN.SomeThing instead of cn.SomeThing? I will try enabling the deeper parsing.
Edit: Reporting back... This does improve ALT-G behavior when full 'begin/end namespace' is used. I notice the Context and Definition windows above the source window do not show the same names, however it still works fine. Eg. hovering over the .cpp now shows cn.SomeThing while the .h still shows NAMESPACE_CN.SomeThing. |
Edited by - GregDude on Apr 26 2013 5:52:17 PM |
|
|
|
Topic |
|
Alt-G Goto will not go to source from header
