| T O P I C R E V I E W |
| smeuser |
Posted - Sep 10 2007 : 08:51:43 AM
Hi,
since some time Alt+G stopped working here for definition (VS2005 C++, VAX 1559).
If I on a symbol (e.g. function name) ALT+G (as well as the GO-Button) goes directly to the declaration. Once more ALT+G (or GO) does not work.
This is nearly always the case.
In some rare cases, the first ALT+G gives me the choice to jump to the definition.
It does work, if I move to the source file and use 'reparse current file'. Then the next ALT+G to that file works (probably until I restart VS2005).
I have already rebuild the database several times, but this was no help.
regards,
Stefan
VA_X.dll file version 10.3.1559.0 built 2007.07.06
Licensed to:
VA X: [email protected] (1-user license) Support ends 2008.07.12
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.5.8
DevEnv.exe version 8.0.50727.762
msenv.dll version 8.0.50727.762
Font: Courier New 13(Pixels)
Comctl32.dll version 6.0.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
2 processors
Platform: Win32
Stable Includes:
D:\\Programme\\Microsoft Visual Studio 8\\VC\\include;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
D:\\Programme\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Library Includes:
Q:\\trolltech\\qt-win-commercial-4.3.1include\\QtCore;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfcm;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
D:\\Programme\\Microsoft Visual Studio 8\\VC\\crt\\src;
Other Includes:
|
| 30 L A T E S T R E P L I E S (Newest First) |
| .oisyn |
Posted - Nov 15 2007 : 5:32:44 PM
Great, thanks! |
| sean |
Posted - Nov 10 2007 : 2:54:54 PM
case=9664 is fixed in build 1616
|
| sean |
Posted - Nov 03 2007 : 12:22:45 AM
Pressing escape after landing in the new file seems to fix this. |
| .oisyn |
Posted - Nov 02 2007 : 6:06:47 PM
I'm glad to see you were able to reproduce it. I was starting to think it was just in my head :) |
| feline |
Posted - Nov 02 2007 : 5:20:32 PM
Cross posting  I have reproduced this with default intellisense enabled.
I have put this in as a high priority bug, so hopefully it will be fixed soon. Thank you for your patience and hard work in tracking down the steps to reproduce this! |
| feline |
Posted - Nov 02 2007 : 5:19:01 PM
I have moved over to a winXP SP2 machine running VS2005 and VA 1561
First test using my current VA and IDE settings, I create a new C++ Win32 Project (so Not a console application) and left it set to "Windows application" in the wizard, and selected "Empty project".
This was created in the directory "C:\\src_2005\\", in its own subdirectory. So all local, nothing to fancy there.
Add the main.cpp file via right clicking in Solution Explorer, and add the code you posted. I typed in the code, accepting VA suggestions - in case this matters.
No problems at all.
Second test, again using my current settings, I created a new C++ Win32 Console Application, again selecting an empty project.
And I have reproduced the problem!!!
Scrolling with the mouse wheel in the file is "fine", the problem persists.
As soon as I use page up a couple of times VA starts updating.
Now lets see if I can reproduce this.
Closing the IDE, loading the IDE and re-opening this project a second time lets me reproduce the problem.
Delete the NCB file, to make the project nice and small for attaching to a bug report, and the problem goes away.
Make a new console project, I can reproduce this. I can also reproduce it in VA 1614, so long as I stick to these steps:
case=9664 |
| .oisyn |
Posted - Nov 02 2007 : 4:48:08 PM
Oh btw, all the machines I have tested this on have the default intellisense disabled by renaming feacp.dll. Don't know if it matters but just thought I'd better mention it :) |
| .oisyn |
Posted - Nov 02 2007 : 11:04:29 AM
Aargh, you're conspiring against me!!! ;)
System info is below. These are the things that I did:
- Start visual studio
- new project, win32 app, empty project
- add new file, main.cpp
- type:
#include <windows.h>
HWND hwnd;
- click on HWND, do alt-g
- in windows.h, wait a few seconds, then do alt-g again. Choose any one of the suggestions.
- in winnt.h, move the cursor around with the mouse. The bug appears.
I've exported my VA X settings from the HKCU/software/wholetomato/VAX key here: http://www.oisyn.nl/vaxsettings.reg: (I anonymized my e-mail in the AboutInfo value though). Perhaps it's important to mention that I have manually set the SuggestionSelect setting to 2.
System info: XP+SP2, VS 2005+SP1, VA X 1561
VA_X.dll file version 10.3.1561.0 built 2007.09.13
Licensed to:
*************************************
VAOpsWin.dll version 1.3.2.7
VATE.dll version 1.0.6.1
DevEnv.exe version 8.0.50727.762
msenv.dll version 8.0.50727.762
Font: Courier New 13(Pixels)
Comctl32.dll version 6.0.2900.2982
Windows XP 5.1 Build 2600 Service Pack 2
2 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft DirectX SDK (August 2007)\\Include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\common\\include;
C:\\Program Files\\Microsoft Visual Studio 8\\SDK\\v2.0\\include;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
|
| feline |
Posted - Nov 02 2007 : 09:49:01 AM
Using win2k, VS2005 and VA 1561 I have created a new, default "C++ -> Win32 Project", accepting the default settings.
I used right click in Solution Explorer to add a new file to the "Source Files" node, and added the new file "new_file.cpp"
I added the following code to the file:
#include <Windows.h>
static void testAltGOnHwnd()
{
HWND wFoo;
}
Without saving the file I placed the caret in the middle of HWND and pressed alt-g. This took me to:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include\\windef.h - line 207
I then immediately pressed alt-g. Nothing happened, so I waited a couple of seconds, and then pressed alt-g a second time. Now I was offered two destinations. I selected the top item, and was taken to:
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\PlatformSDK\\include\\winnt.h - line 335
Using only the mouse, and only clicking in the visible code, so no scrolling, the VA context and definition fields are being updated as I click into different items, and the alt-g menu is appearing some of the time when I press alt-g. Only some items offer the alt-g menu. "HRESULT" on line 354 offers the alt-g menu.
I have just saved the "new_file.cpp", closed VS2005 (saving the changes to the project) and reloaded the solution. I then tried the alt-g test again, on the existing file and code, and again everything is working perfectly.
Your instructions are quite clear, thank you for this.
The fact you are seeing this on several different machines suggests there is some key difference between what I am doing and what you did.
Which OS, IDE and version of VA are you using?
Are you seeing anything in my description of what I did that looks wrong? |
| .oisyn |
Posted - Nov 01 2007 : 9:00:51 PM
Ok I think I managed to reproduce it using a very simple project, using windows.h :)
Create a new C++ project, add a sourcefile, and include windows.h in it. Define a variable of the type 'HWND' (be sure to complete the whole definition - if you just type HWND, it won't work), place the cursor over the HWND part and do alt-g. This brings you to a line saying DECLARE_HANDLE(HWND), and press alt-g immediately again. VA X asks which one, as there are two DECLARE_HANDLE definitions located in winnt.h. Choose either one. Congratulations, you have now reproduced the bug (at least I hope, but I'm getting this on several machines so I know it isn't just my config). If you move the cursor within winnt.h by using the mouse, the navigation bar won't get updated and you won't be able to do alt-g commands |
| feline |
Posted - Oct 17 2007 : 08:19:21 AM
I know the problem with being very busy, it happens to all of us sooner or later
I am honestly not sure what to make of this, so if you are able to reproduce this in a smaller project that would be very interesting. |
| .oisyn |
Posted - Oct 16 2007 : 06:22:09 AM
Sorry for my late reply, I have been very busy at work the past couple of weeks so I didn't have the chance to install the new version. But today I did, and I'm still experiencing the issues. The situation I described earlier, with the three different sourcefiles - it turns out this isn't actually needed to reproduce it. I can currently reproduce it with only one jump from one sourcefile to another. Another interesting thing to note is that, when I click-drag the mouse in the sourcefile when I'm experiencing the problem to select a piece of text, the navigation bar displays a different context (such as: MyClass.~MyClass.for.if.if). This context is totally unrelated to the selected text (but is related to the current sourcefile), and it's the same every time. When I unselect the text, it jumps back to it's previous context (also totally unrelated to the current cursor position and the same *every*time* I reproduce it, such as: MyClass.m_someMember). Again, this is all fixed as soon as I press a keyboard key that moves the cursor or changes the sourcefile.
I shall see if I can manage to produce a small project that shows the problem. |
| feline |
Posted - Sep 24 2007 : 11:30:12 AM
I am still not having any success reproducing this problem. The fact it happens some of the time, in a reproducible manor interests me. I am wondering if there is some form of parser problem at work, almost as if VA is slightly confused by some files.
I have emailed you about this.
You know a specific context, assuming this uses the three files "fooA.cpp", "fooB.cpp" and "fooC.cpp" do you have the time to copy just these files and add then to a new default console project?
I am not interested in making the project compile, just a very quick and simple test, to see if the alt-g problem shows up in this simple project as well.
This would eliminate the size of the main solution, and several other factors. |
| .oisyn |
Posted - Sep 24 2007 : 07:59:09 AM
It doesn't happen all the time, it depends on the context. But within such a context, if it happens it is 100% reproducable by taking the exact same steps.
It always involves doing alt-g on symbols that lead to other files (no matter whether those other files are already opened or not). After browsing through 2 or 3 files by clicking on a symbol with the mouse and then doing alt-g, VA X no longer respons on cursor changes that are done by mouse. As soon as you press a key that changes the cursor, or you move the focus to another window (with the mouse), it starts tracking cursor changes by mouse again. |
| feline |
Posted - Sep 18 2007 : 1:35:11 PM
The reference to tapping the cursor key suggests you are doing all of the movement by clicking on symbols with the mouse.
I have just tried some alt-g tests here, clicking on symbols with the mouse, and I am not seeing any problems.
Can you explain in detail what you are doing? I suspect I am doing something quite different to you, which is why I am not seeing any problems. |
| .oisyn |
Posted - Sep 14 2007 : 8:15:47 PM
They're files that are already opened in the editor. Doesn't matter if they're large or small. And besides, it works when tapping a cursor key, so I don't think parse times are the issue. It just seems that VA X isn't responding to cursor changes by mouse. Also, it doens't matter how long I wait before moving the cursor. |
| feline |
Posted - Sep 14 2007 : 09:48:09 AM
What size of files are you jumping into? Are they tiny files? Massive files? Or does this not make any difference? |
| AGPX |
Posted - Sep 14 2007 : 08:47:24 AM
Same thing happens for me too |
| feline |
Posted - Sep 14 2007 : 07:59:55 AM
Does this seem to happen with all files, or only "large" files? What you are seeing sort of reminds me of the effect being reported in this thread:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=6669
I am wondering if the time taken for VA to parse the file you have just opened is a factor here as well. If you are jumping into 20 line files then this should not be a factor, but if you are jumping into files that are many thousands of lines long then it might be a factor. |
| .oisyn |
Posted - Sep 14 2007 : 07:02:26 AM
I've 'disabled' the IDE's own intellisense parser as it is causing major stalls with our huge projects (disabled as in renaming that dll file). I don't see any CPU spike when the navigation functionality appears to be not working. It's just that: it's not working. Until I press alt-m.
Wait, while typing this post, I found out that moving the focus from the text editor to any other window (either in the IDE itself or another application) and then back to the text editor causes the navigation to work again. Also, when pressing one of the cursor keys it works as well. So it seems VA X is simply not responding to cursor changes by mouse. |
| feline |
Posted - Sep 13 2007 : 5:31:46 PM
Can you run a CPU meter please? I am wondering if you are seeing / experiencing some form of CPU spike, or hard drive access spike that is slowing everything right down. This might make sense if the file you have just landed in has not been opened since you started the IDE and VA or the IDE is busy parsing it.
Which IDE are you using? CPU spikes are mainly a problem in VS2005 with the IDE's intellisense parser enabled. |
| .oisyn |
Posted - Sep 13 2007 : 1:13:46 PM
Ok it just happened again. The navigation bars are not empty, it's more like hanging on one of the identifiers in the file. I can fully reproduce it - by doing alt-g that navigates to another file, and then doing alt-g in that other file again that navigates to yet another file, any further navigation and the navigation bar don't work in that third file (the bar shows some identifier the cursor is not placed on). After doing alt-m, I see a list of methods, and from then on the navigation works fine again. |
| .oisyn |
Posted - Sep 13 2007 : 12:54:52 PM
No the stable files merely exists of the standard VC++ include paths. I'll try the alt-m thing next time I encounter the problem |
| feline |
Posted - Sep 12 2007 : 08:49:44 AM
It almost sounds like VA has not finished parsing the file. This would explain why the definition field is not showing you anything. When you get this problem if you open the alt-m list do you see anything?
I would not expect duplicate files on their own to cause a problem, but it is possible.
If you look at your stable include directories in VA options -> Projects -> C/C++ Directories
Do these directories overlap with your project directories? I.e. are you working in and editing files that VA thinks are stable? This can confuse VA, since VA knows it needs to keep on parsing your code while you edit it, while stable code does not get re-parsed at all often. |
| .oisyn |
Posted - Sep 11 2007 : 4:33:33 PM
I'm seeing this a lot too, but I don't think it has anything to do with symbol parsing or whatever. If I use alt-g to jump to a symbol, VA X doesn't seem to understand the symbols in the file I just jumped to (the navigation bar remains empty when moving the cursor to the symbol, and alt-g doesn't work). The funny thing is, if I switch to another file and back to the former, it's suddenly working again.
I'm using 1559, and I'm seeing this very often. I also have the 'reparse all symbols in project' option enabled.
Btw, I don't think it's in any way related to this, but it might be worth noting that we're using softlinks for our projects. We are working on two large projects, and we have a large library which is used by both projects. That library is located somewhere on the harddrive, but also softlinked into the two project folders. Since I'm working mainly in the library, I usually have both projects open in seperate visual studios to test my work. Perhaps this is confusing Visual Assist, as d:\\projectA\\library\\file.h and e:\\projectB\\library\\file.h are actually the same file? |
| feline |
Posted - Sep 11 2007 : 12:04:12 PM
To be honest I don't really have a complete answer for you on this one. A partial answer is that VA tends to parsed included header files when you open a cpp file. You often see them flash by on the status bar, especially for the bigger and more complex header files which take longer to parse. Boost template header files are a good example of this effect. |
| smeuser |
Posted - Sep 11 2007 : 10:32:32 AM
Yes, files may be changed outside the control of VA in my case.
But why VA finds the declarations (with disabled parse option)?
It seems only to forget about the definitions... (nearly all definitions, not all - and the files have not be changed for a long time - even the rebuild database did not help)
If VA already found the header, it should be at least possible to look into the corresponding source file for the definition.
|
| feline |
Posted - Sep 11 2007 : 08:27:23 AM
I actually thought the same thing myself, about this being a bug, but this is actually by design.
One factor to consider is that most people working on large projects work as part of a group, using source control, so each time you load the IDE there is a good chance that quite a few files will have been changed by the source control system, completely outside of VA's knowledge.
So VA cannot assume that what it knew last time about your project is still valid. |
| smeuser |
Posted - Sep 11 2007 : 04:48:18 AM
IntelliSense is disabled (because of its slowness).
But it's okay for me, to have the option 'Parse all files when opening a project' enabled. It's a workaround and it's fine.
My last comment was meant, that even for me it's okay, it looks like there is a bug, if the option is disabled. |
| feline |
Posted - Sep 10 2007 : 4:27:21 PM
Unfortunately this is a trade off between speed of loading the IDE, and usefulness once the IDE is loaded. For most people having the option turned on does not cause any problems, but it is there for people with very large solutions.
It is possible that some, or even a lot of the delay is caused by both VA and VS2005 scanning your code when you load the IDE. This FAQ explains about disabling the IDE's intellisense scanner, which can make a lot of different to how quickly / slowly things run:
http://docs.wholetomato.com?W133 |
|
|
