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 goes always to the decleration (header file)

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
satya Posted - Apr 02 2007 : 03:16:07 AM
Hi,

I am facing a strange problem from quite sometime. Whenever I use Alt+g (Go) on a symbol VA always takes me to the header file and not the C/C++ file where I have the definition. Earlier I used to get a list and I could select the header file or the source file, but now it always automatically takes me to the declaration only (not the definition)

currently I am using the VA_X.dll file version 10.3.1548.0 built 2007.02.23 and I am not very sure from when I started getting this problem.

I am using VS2005 on a Windows x64

Can you please help me resolve this issue

TIA
Satya


17   L A T E S T    R E P L I E S    (Newest First)
support Posted - May 31 2007 : 01:08:05 AM
fixed in build 1557
feline Posted - Apr 24 2007 : 10:36:42 AM
I am not sure about the files, but you certainly should not be seeing exceptions logged with this enthusiasm. Thank you for these details, I have updated the case with them. Hopefully they will help.
jameso Posted - Apr 24 2007 : 08:34:30 AM
It's back again :/

I noticed earlier that most of the .idx files in va\\vs8\\proj_xxxxxx\\ have an accompanying, much larger, .tmp file (while devenv is running) There are also a bunch of .tmp files in the cache directory.

When I close devenv normally, the .tmp files in proj_xxxx have gone. However, the cache versions are still there:


 Directory of C:\\...\\Application Data\\VisualAssist\\vs8\\cache

24/04/2007  10:57    <DIR>          .
24/04/2007  10:57    <DIR>          ..
24/04/2007  13:22           449,708 Db0Ds.db
24/04/2007  13:22             2,784 Db0Ds.dbx
24/04/2007  13:22           156,744 Db0Idx.db
24/04/2007  13:22             2,760 Db0Idx.dbx
24/04/2007  13:22           878,311 Db1Ds.db
24/04/2007  13:22             2,304 Db1Ds.dbx
24/04/2007  13:22           245,760 Db1Idx.db
24/04/2007  13:22             2,304 Db1Idx.dbx
24/04/2007  13:22           642,094 Db2Ds.db
24/04/2007  13:22             3,096 Db2Ds.dbx
24/04/2007  13:22           211,440 Db2Idx.db
24/04/2007  13:22             3,096 Db2Idx.dbx
24/04/2007  13:04           459,382 Db3Ds.db
24/04/2007  13:04             2,424 Db3Ds.dbx
24/04/2007  13:04           137,520 Db3Idx.db
24/04/2007  13:04             2,424 Db3Idx.dbx
24/04/2007  13:02           664,425 Db4Ds.db
24/04/2007  13:02             2,664 Db4Ds.dbx
24/04/2007  13:02           216,312 Db4Idx.db
24/04/2007  13:02             2,616 Db4Idx.dbx
24/04/2007  08:35             3,322 M13118203.d1
24/04/2007  08:35         2,787,390 m14678747.d1
24/04/2007  08:35            62,151 S12692972.d1
24/04/2007  08:35           160,404 S14253048.d1
24/04/2007  08:35         2,012,706 S15443749.d1
24/04/2007  08:35             8,729 S2610137.d1
24/04/2007  08:35           604,575 S3849407.d1
24/04/2007  08:35         1,053,544 S5493357.d1
24/04/2007  08:35           457,929 S5702156.d1
24/04/2007  08:35         5,559,370 S8868275.d1
24/04/2007  13:23            88,369 VA_A.tmp
24/04/2007  13:23            22,630 VA_B.tmp
24/04/2007  13:23           159,973 VA_C.tmp
24/04/2007  13:23            59,763 VA_D.tmp
24/04/2007  13:23            19,935 VA_E.tmp
24/04/2007  13:23            74,772 VA_F.tmp
24/04/2007  13:23           301,299 VA_G.tmp
24/04/2007  13:23            19,222 VA_H.tmp
24/04/2007  13:23           227,649 VA_I.tmp
24/04/2007  13:23             6,081 VA_J.tmp
24/04/2007  13:23               297 VA_K.tmp
24/04/2007  13:23            35,784 VA_L.tmp
24/04/2007  13:23            43,970 VA_M.tmp
24/04/2007  13:23            16,108 VA_N.tmp
24/04/2007  13:23            13,391 VA_O.tmp
24/04/2007  13:23            28,261 VA_P.tmp
24/04/2007  13:23             1,187 VA_Q.tmp
24/04/2007  13:23            45,020 VA_R.tmp
24/04/2007  13:23           282,592 VA_S.tmp
24/04/2007  13:23            18,193 VA_T.tmp
24/04/2007  13:23            13,257 VA_U.tmp
24/04/2007  13:23            20,981 VA_V.tmp
24/04/2007  13:23            17,904 VA_W.tmp
24/04/2007  13:23               223 VA_X.tmp
24/04/2007  13:23               217 VA_Y.tmp
24/04/2007  13:23                44 VA_Z.tmp
24/04/2007  13:23            22,482 VA__.tmp
              57 File(s)     18,337,892 bytes
               2 Dir(s)  20,730,007,552 bytes free


08:35 is (roughly) when I restarted the IDE to install 1544. 13:22/13:23 is roughly when I closed devenv to see what happened. There's also an errors.log containing:


Exception: VACS::1465 4/24/2007 08:46:39 0xc24
Exception: EDC::1139 4/24/2007 11:04:01 0xcb0
Exception: EDC::1139 4/24/2007 11:04:01 0xcb0
Exception: EDC::1139 4/24/2007 11:04:01 0xcb0
Exception: EDC::1139 4/24/2007 11:04:01 0xcb0
Exception: EDC::1139 4/24/2007 11:04:01 0xcb0
Exception: EDC::1139 4/24/2007 13:03:05 0x734
Exception: EDC::1139 4/24/2007 13:03:05 0x734
Exception: EDC::1139 4/24/2007 13:03:05 0x734
Exception: EDC::1139 4/24/2007 13:03:05 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:06 0x734
Exception: EDC::1139 4/24/2007 13:03:16 0xb90
Exception: VACS::1465 4/24/2007 13:05:32 0xc24
Exception: VACS::1465 4/24/2007 13:05:33 0xc24
Exception: VACS::1465 4/24/2007 13:05:34 0xc24
Exception: VACS::1465 4/24/2007 13:05:37 0xc24


I don't know if this is normal behaviour, it just seems a bit odd. (To give you an idea of the data size, the source is roughly 4500 files across 80 projects totalling about 40M (.cpp/.h))
feline Posted - Apr 18 2007 : 08:55:37 AM
Patience is good, it is just I thought we had fixed this, so it is a little frustrating to see it come back again

This two IDE's, two copies of the solution situation, I can reproduce a problem with alt-g, but only while both IDE's are running.

Close both IDE's and reload either project and the problem goes away. No need to delete any files on the hard drive.

This is using VS2005 and VA 1553

case=6078
jameso Posted - Apr 18 2007 : 03:13:00 AM
Well, it's possible that the problem occurred last time when I opened (almost identical) copies of the same solution in two different directories at the same time, if you see what I mean? (Same source, duplicated in two directory trees, both parented in C:\\, open in two instances of VS at the same time)

None of the source is in a stable include directory.

Have patience, we'll work the problem - I'm not in any great hurry. We'll just have to look at what's happened when it presents and try to work out why. In the meantime, I have a bunch of work which VA is helping me with :)

James
feline Posted - Apr 17 2007 : 5:17:59 PM
*sigh* so its not up time.

Any ideas, or clues, as to the cause? Anything odd or strange going on?
Is your source code located in a stable include directory?
Using "subst" to map local directories to drive letters?

I am not sure where to start to be honest.

I would like to avoid log files, when the problem can take 2 weeks to show up, that would be a LOT of logging, plus it gets turned off at every IDE restart.
jameso Posted - Apr 17 2007 : 12:54:45 PM
Yes, fresh files were created in the recreated directories

I'll check date stamps next time, just in case.

Yes, it's been a couple of weeks, and it's generally been OK (I did toast a hard disk, but I'm not blaming VA for that ;) (It was the second drive in the machine, I got the source from source safe on C and just carried on with no problems)

We're meant to shut down overnight for the sake of the electricity bill, I do about 2/3 of the time, so the uptime is normally not more than a couple of days. I restart visual studio for one reason a little bit more frequently, but generally try to avoid it.

James
feline Posted - Apr 17 2007 : 12:49:12 PM
The exception looks like it is related to a VA listbox, which makes sense.

When you deleted the subdirectories and they were re-created do you know if fresh files were created inside of them?

It is as if one of the files in the directory:

C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\
told VA not to bother rebuilding the files, or was part of the problem.

I can see how the "version.dat" file in this directory will tell VA not to bother rebuilding the directories if there is no need, but if all files have been deleted it should do the rebuild.

Looking at the dates here it has been a couple of weeks since you posted about this problem. Has VA been working correctly for a couple of weeks, or did this break more quickly?

If you keep your machine on all the time, with the IDE running, I am wondering if uptime is a problem. To be honest this is a wild guess, but something is clearly causing you problems.
jameso Posted - Apr 17 2007 : 03:44:43 AM
It broke for me again - on my new machine (twice) :(

Still, here's some information which is probably not going to be very helpful, but next time it happens, I'll try doing smaller things

First time, I had an upgrade pending, so I uninstalled and deleted everything still lying around which looked like VA data, then installed and it was happy again.

This morning it broke again, this is what I did:

- closed VS
- Deleted the following directories
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\cache
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\CPP
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\history
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\imports
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\Sys
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist\\vs8\\typeHist

But that made no difference when I restarted, though the directories were all re-created

- I deleted all the proj* subdirectories in VA\\vs8, but that didn't help either
- I renamed
C:\\Documents and Settings\\jameso\\Local Settings\\Application Data\\VisualAssist to VA.old and restarted

And that worked (alt-g caused a flurry of parsing (I have "parse all symbols when opening a project" off) and then it went to the implementation.

There was an exception logged yesterday:
Exception: VACS::1465 4/16/2007 13:19:58 0xda0

Which may have been about when it broke (yesterday afternoon was mainly a meeting afternoon, not an actual work afternoon)

Any suggestions about drilling down further?

James
feline Posted - Apr 04 2007 : 10:48:42 AM
You should not need to uninstall VA before installing the new build, and personally I never uninstall VA, before installing the new build.

Still I am glad this worked for you At a guess there was a problem with the VA settings in the registry, but I may be wrong in this guess.
satya Posted - Apr 04 2007 : 09:59:29 AM
Hi,

I am able to get my problem solved. I am not very sure how I got it solved, but this is what I did. Always I used to install the latest version of VA without uninstalling the previous version. Now I just did an uninstall and installed the new version. and I was happy to see that VA was parsing the .c and .cpp files of my project when I loaded my sln file

Thanks for your time and I guess something goes wrong if I just do an install of the newer version without uninstalling the older one

Thanks again
Satya
feline Posted - Apr 04 2007 : 08:48:47 AM
Please submit the test application via the form:

http://www.wholetomato.com/support/contact.asp

including this thread ID or URL in the description, so we can match it up.

This is a little odd, and I am wondering why you never see the .c files being parsed. My first reaction is to suggest the problem .c files are not known to VA. If you close the .c file does it still show up in the OFIW dialog? Is it actually listed in the IDE's solution explorer?
satya Posted - Apr 04 2007 : 02:15:59 AM
I too hope that I don't have to change my machine

The problem appears in a project which is mostly made of c (not cpp) sources. So there is no question of classes or namespaces.

Alt+g takes me to the correct place in the header file.
in the cpp file alt+m works fine. (as jameso, I too like this option)
you mean the find next and previous by context? this works fine

I forgot to tell you one important thing (I guess) if I remove the database and load the IDE again or whenever the VA parses the files, I never see the .c or .cpp files getting parsed for which the alt+g fails to work

I will prepare a sample console application and send you by end of the day

TIA
Satya
feline Posted - Apr 03 2007 : 08:18:25 AM
I agree, it does sound a lot like that thread. Lets try a few basic tests first before I recommend you ask for a whole new machine

* If you are sitting in the cpp file does alt-g take you to the correct place in the header file?
* In these problem cpp files (the ones alt-g will not jump into) does the alt-m list work correctly?
* In these problem cpp files does Next and Previous scope work correctly?

If you take a problem cpp file, and its matching header file, and place them into a new default console project do you still see this problem?

If you can reproduce the problem like this I am wondering if you can simplify the files right down (deleting most of the code) to the point where you could send me a copy of the files, so I can try to reproduce the problem here.
jameso Posted - Apr 03 2007 : 05:36:24 AM
Have a look at this thread:

http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=5895

I fixed it with a new PC, but that was probably a bit of an over-reaction. I'm sure it's a bug though, just a problem to reproduce.

James
satya Posted - Apr 03 2007 : 02:50:14 AM
Hi,

I installed the 1549 and there is no change. I have some of the sources files in the OFIW and it is the same even for the symbols defined in those files. It is happening for all the symbols. It works fine if the symbol is defined in the same file.

Even an alt+g in the header file doesn't take me to the definition in the source file

My project has both C and C++ files and the problem occurs for both.

TIA
Satya
feline Posted - Apr 02 2007 : 09:44:22 AM
Can you please try upgrading to VA 1549 to see if this makes any difference:

details here:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6019

direct download link:
http://www.wholetomato.com/downloads/VA_X_Setup1549.exe

I recall a similar problem a little while ago, when the cpp file contained a lot of "using namespace foo" lines, but this particular problem was fixed.

Are you seeing this problem with all functions and classes, or only some of them?
Are the cpp files listed in the OFIW dialog?
Once you are in the header file does alt-g take you to the cpp file?

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