Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
 All Forums
 Visual Assist
 Technical Support
 Alt-G Goto will not go to source from header

You must be registered to post a reply.
Click here to register.

Screensize:
UserName:
Password:
Format: BoldItalicizeUnderlineStrikethrough Align leftCenterAlign right Insert horizontal ruleUpload and insert imageInsert hyperlinkInsert email addressInsert codeInsert quoted textInsert listInsert Emoji
   
Message:

Forum code is on.
Html is off.

 
Check to subscribe to this topic.
   

T O P I C    R E V I E W
JanSolo Posted - Jan 06 2012 : 6:15:48 PM
Using: VA_X.dll file version 10.6.1850.0 built 2011.06.07

When I use Alt-G on a function name in my project, I'm taken to the definition of that function in its header(.h).
However, when I Alt-G on the definition, I expect to be taken to the body of the function in the source(.cpp) file. This does not work for me.

Alt-G only ever takes me to the header definition, never the source file. It's very annoying.

I searched and problem is almost identical to this one from a few years ago:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=8901

Notes:
The function is listed correctly in Alt-M.
It's also listed in 'Find Symbols'.
Alt-Up/Down correctly jumps to the Next/Prev functions in the file.
"Parse all files when opening a project" is ON.
"Reparse Current File" doesn't help.



Any ideas/fixes?

Thanks!
30   L A T E S T    R E P L I E S    (Newest First)
GregDude 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.
accord 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 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.
accord 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
GregDude 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 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 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.
support 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
feline 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.
pthiben 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 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?
pthiben 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
support Posted - Sep 13 2012 : 2:16:34 PM
The regression was case=68625 and is fixed in build 1916
feline 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.
pthiben 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 Posted - Aug 27 2012 : 2:05:23 PM
Excellent news, thank you for the update
vjtech 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 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.
pthiben Posted - Aug 24 2012 : 3:53:49 PM
1912 seemed to resolve most of our cases here.

Unfortunately, I can't repro the remaining files that still have the problem =/
pwc Posted - Aug 24 2012 : 3:30:20 PM
I'm seeing the same thing (alt-g doesn't navigate from header to source). This pretty much renders 1912 unusable.
vjtech Posted - Aug 22 2012 : 03:59:13 AM
I tried the proposed solution, unfortunately it did not help.
The behaviour is exactly the same as before.
I will try to make a simple project reproducing the issue and send it to support
mentioning case number which was sent to me in e-mail.

Thanks for help.
sean Posted - Aug 21 2012 : 9:35:03 PM
mail sent to benblo and vjtech via support
vjtech Posted - Aug 21 2012 : 09:55:45 AM
Yes, the problem appears to be after custom BEGING END construction using custom made message map.
All macros are defined in .h header file.

In .cpp file I have the construction shown below.
Before this BEGIN END block everything works ok.
After this block Alt-G stops working

.cpp file
BEGIN_MY_MESSAGE_MAP(CItemList,CSomeWindowBase)
ON_MY_MESSAGE( WM_ITEM_EVENT, OnItemEvent )
ON_MY_MESSAGE( WM_LBUTTONDOWN, OnLButtonDown )
ON_MY_MESSAGE( WM_HANDOVER_LBUTTONDOWN, OnHandoverLButtonDown )
ON_MY_MESSAGE( WM_LBUTTONUP, OnLButtonUp )
ON_MY_MESSAGE( WM_MOUSEMOVE, OnMouseMove )
ON_MY_MESSAGE( WM_SET_LIST_VELOCITY, OnSetListVelocity )
ON_MY_MESSAGE( WM_TIMER, OnTimer )
END_MY_MESSAGE_MAP()

Please let me know if you need more information on message map definitions.
benblo Posted - Aug 21 2012 : 08:46:43 AM
Reverting to build 1901 "fixed it" for me... it's back to the old icons for me ;) !
Shame because 1912 seemed to have nice improvements.
benblo Posted - Aug 21 2012 : 08:38:51 AM
Same problem here, alt+g only ever brings me to the .h, never the .cpp. This is global, all the code, the whole solution, not just some classes.

If I alt+g from another class, I don't have the dropdown I had before asking for the location ("h or cpp"), and if I alt+g from the h it stays there, still doesn't bring me to the cpp.
I checked, alt+g is still mapped to the "goto implementation" command.

I'm on VC++ 2010 10.0.30319.1 RTMRel, Visual Assist X 10.7.1912.0 build 2012.08.08.

I tried to rebuild the symbol DB and clear history & cache, no dice.
feline Posted - Aug 20 2012 : 2:09:53 PM
Do you have this problem with all code, or with only some code?

You mention turning on macro parse depth, so is this problem only showing up on code that uses macros? Would you be able to post a simple code sample that shows the problem you are having?
vjtech Posted - Aug 20 2012 : 05:28:09 AM
Using following:
MS VisualStudio 2008 C++
VA build 10.7.1912.0

Alt-G (or Go button) still does NOT take you to .cpp file
You can jump from .cpp file to header but not from header to .cpp file

Tried re-parsing files and rebuilding VA databases, nothing helped.
Tried 'Macro parse depth' solution: no luck.

If you use 'Find References' option, it displays the correct list of references and you can jump to .cpp location from there.
If you display 'Code definition' window, it will display the correct file/location.
It if just Alt-G which does not want to work.


Alt-G is the most frequently used function (by me)
Needless to say that this issue is very annoying.
Best of luck in finding it.
support Posted - Aug 09 2012 : 01:57:38 AM
case=14901 is fixed in build 1912
pthiben Posted - Apr 24 2012 : 4:55:17 PM
quote:
Originally posted by feline

Unfortunately yes, I am able to reproduce with your example, and so far the only work around I can find is to search in the Find Symbol dialog, or to use Find References, since this is listing all instances of the function for me.

This is going to be slower than Alt-g, but hopefully this is reliable for you.



That's good news for me at least :)

I hope this example is simple enough to track down this nasty bug

Thanks
feline Posted - Apr 24 2012 : 4:33:35 PM
Unfortunately yes, I am able to reproduce with your example, and so far the only work around I can find is to search in the Find Symbol dialog, or to use Find References, since this is listing all instances of the function for me.

This is going to be slower than Alt-g, but hopefully this is reliable for you.

© 2023 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000