| T O P I C R E V I E W |
| Rasmuss |
Posted - Feb 16 2006 : 08:50:56 AM
Using ifdef else around an if statement will make all methods after it not show up in the method list.
How to reproduce:
Paste the following into a new cpp file:
bool CTest::Test0() {
return false;
}
bool CTest::Test1() {
if(test1) {
#ifdef TEST
if(test2) {
#else
if(test3) {
#endif
test4++;
}
}
return false;
}
bool CTest::Test2() {
return false;
}
bool CTest::Test3() {
return false;
}
This will make only the Test0 and Test1 function show up in the method list (alt+m).
If you comment out the ifdef from Test1 so it will look like this:
//#ifdef TEST
if(test2) {
//#else
// if(test3) {
//#endif
It should then show all 4 functions in the method list.
I have tried this on a couple of my colleagues machines with older versions of VA:
VA.NET 7.1.1106 works.
VAX 10.1.1297.0 works.
Regards,
Rasmus Sigsgaard
P.S. Any news on case=876 http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4142  ?
VA_X.dll file version 10.2.1440.0 built 2006.01.17
Licensed to:
VA X: ioi.dk (45-user license) Support ends 2007.02.09
VA.NET 7.1: ioi.dk (45-user license)
VAOpsWin.dll version 1.3.2.0
VATE.dll version 1.0.4.12
DevEnv.exe version 7.10.3077.0
msenv.dll version 1.0.5849.1
Font: Courier New 13(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
4 processors
Platform: Win32
Stable Includes:
C:\\Program Files\\Microsoft Xbox SDK\\Include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;
Library Includes:
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;
Other Includes:
|
| 14 L A T E S T R E P L I E S (Newest First) |
| jbusby |
Posted - Aug 31 2006 : 8:04:08 PM
quote:
Originally posted by support
rhummer is correct.
Mismatched braces caused by your #ifdefs confuses the IDE and certainly confuses VA X. With VA X, all code in your #ifdefs is parsed during edit since you are writing/edting all of it. (VA X does not ignore certain #ifdef'd code because you might not #define the guard in the next compile.)
See "Errant Context" at the bottom of:
http://www.wholetomato.com/products/features/context.html?more=yes
I don't agree that this is an IDE problem. I am experiencing the same problem with braces inside an #ifdef/#else construct causing subsequent functions to be absent from the browser list. The syntax colouring in both the #ifdef part and the #else part is fine however, as is the colouring of the subsequent functions. Also, Visual Studio 2005's own class browser has no trouble showing all the functions in the file, which suggests it is not an IDE problem. Only VAX seems to have a problem, and if previous versions worked then it would suggest that this is a recently introduced parsing bug that warrants a fix in a future release?
---------------------------------------------------
VA_X.dll file version 10.2.1446.0 built 2006.05.31
Licensed to:
VA X: [email protected] (20-user license) Support ends 2007.03.07
VA.NET 7.1: [email protected] (15-user license)
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.4.14
DevEnv.exe version 8.0.50727.42
msenv.dll version 2.0.3115.0
Font: Courier New 11(Pixels)
Comctl32.dll version 6.0.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
2 processors
Platform: Win32
Stable Includes:
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\\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\\mfcm;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\atlmfc\\src\\atl;
C:\\Program Files\\Microsoft Visual Studio 8\\VC\\crt\\src;
Other Includes:
|
| support |
Posted - Jun 19 2006 : 5:44:26 PM
Fixed in build 1524:
Filtering with OFIW and FSIW dialogs is faster. (case=1001) |
| feline |
Posted - May 18 2006 : 2:39:32 PM
oops, my mistake.
thinking about it (i use FSIW a lot less than OFIW) i am not seeing any such problems with the 15xx beta builds on a similar size solution. this is most odd. hopefully the 15xx builds will be ready for general beta soon and you can try those. not an ideal solution but i am not really sure what else to suggest. |
| Rasmuss |
Posted - May 18 2006 : 03:34:08 AM
quote:
Originally posted by feline
quote:
Originally posted by Rasmuss
But, I just tried installing 1438 again, and whenever I type a character in FSIW it takes about 0.5 seconds before the next character I typed show up, and this is the slowness I was referring to.
*snip*
1438:
OFIW: 5761
FSIW: 109413
i am using the 15xx beta on a solution with over 4,000 files in the OFIW dialog and i am not getting this delay on typing. it could be it has been fixed, or it could be that there is something about your system that is causing this.
one obvious test would be to see if you get the same delay on typing in OFIW with a much smaller project.
Yes, OFIW is not bad since the delay introduced in 1440 was lessened in 1442, but I'm referring to FSIW which filters "instantly" in 1418, and has a "lag" of ~0.5 seconds per character in 1438, which has been "remedied" in 1440 by introducing the hardcoded delay before filtering.
~Rasmus |
| feline |
Posted - May 17 2006 : 3:26:39 PM
quote:
Originally posted by mnd
me too have this problem with build 1445.
I've a small piece of code specific for the mac platform:
#ifdef MACINTOSH
{
// the code inside this block doesn't influence the bug.
}
#endif
i have tried adding this to the middle of a cpp file, using VS2003 and VA 1445 and there are no problems.
i am currently guessing that the problem you are getting is somehow specific to this file. are you able to provide me with a copy of this file (perhaps unlikely), or can you try trimming the file down to see what is causing the problems? |
| feline |
Posted - May 17 2006 : 3:15:57 PM
quote:
Originally posted by Rasmuss
But, I just tried installing 1438 again, and whenever I type a character in FSIW it takes about 0.5 seconds before the next character I typed show up, and this is the slowness I was referring to.
*snip*
1438:
OFIW: 5761
FSIW: 109413
i am using the 15xx beta on a solution with over 4,000 files in the OFIW dialog and i am not getting this delay on typing. it could be it has been fixed, or it could be that there is something about your system that is causing this.
one obvious test would be to see if you get the same delay on typing in OFIW with a much smaller project. |
| mnd |
Posted - May 15 2006 : 03:38:12 AM
me too have this problem with build 1445.
I've a small piece of code specific for the mac platform:
#ifdef MACINTOSH
{
// the code inside this block doesn't influence the bug.
}
#endif
and just after that piece of code VAX seems to be disabled, it doesn't autocomplete the code, in the vax method list doesn't show the remaining methods, color code doesn't show vax extension, autotext doesn't work, evertyhing works like vax disabled.
Regards,
- mn
VA_X.dll file version 10.2.1445.0 built 2006.04.12
Licensed to:
VA X: [email protected] (1-user license) Support ends 2007.01.13
VA.NET 7.1:
VAOpsWin.dll version 1.3.2.4
VATE.dll version 1.0.4.15
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.3077.0
Font: ProFontWindows 15(Pixels)
Comctl32.dll version 5.82.2900.2180
WindowsNT 5.1 Build 2600 Service Pack 2
Single processor
Platform: Custom
Stable Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\include;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include\\prerelease;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\PlatformSDK\\include;
c:\\program files\\microsoft visual studio .net 2003\\sdk\\v1.1\\include;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\includes;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\architecture;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\cjk;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\colormgmt;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\graphics;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\incopy;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\interactive;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\interactive\\ui;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\layout;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\tables;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\text;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\ui;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\utils;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\workgroup;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\interfaces\\xmedia;
C:\\build\\main103\\src\\contrib\\Adobe\\InDesign\\ID-4.0\\source\\public\\widgets\\includes;
C:\\build\\main103\\src\\contrib\\jace\\1.1\\release\\include;
Library Includes:
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\mfc;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\atlmfc\\src\\atl;
c:\\program files\\microsoft visual studio .net 2003\\vc7\\crt\\src;
Other Includes:
|
| Rasmuss |
Posted - Feb 17 2006 : 11:52:22 AM
I am aware of the pause after typing before updating with regards to FSIW, and was actually awaiting it anxiously when I first read about the suggestion. And I must say that using FSIW in 1440 is much better than previously.
But, I just tried installing 1438 again, and whenever I type a character in FSIW it takes about 0.5 seconds before the next character I typed show up, and this is the slowness I was referring to.
In order for you to relate to the amount of files and symbols in the project I'm working on, I managed to find some code (http://www.microsoft.com/msj/0997/win320997.aspx which compiles in VS.NET 2003! ) which allows you to get the content of a listview.
Here are the numbers:
1438:
OFIW: 5761
FSIW: 109413
1418:
OFIW: 5761
FSIW: 114433
While both versions filters "instantly" in OFIW, 1438 has the aforementioned lag of ~0.5 seconds per character, whereas 1418 filters "instantly".
Anyways, I'm currently using 1418 again and it is fulfilling my needs fine. |
| support |
Posted - Feb 17 2006 : 10:34:56 AM
We introduced a new C/C++ parser in build 1421. Apparently, the new parser does not recover as gracefully as the old when finding mismatched braces. We will explore our options going forward. Obviously, we want to make VA X as useful as we can.
In recent builds, FSIW waits for a pause in typing before updating. This is probably what you experience. (We have plans to require the pause only when the list is very large.)
|
| Rasmuss |
Posted - Feb 17 2006 : 05:27:51 AM
I just tried it on a colleagues machine with VA X 1418, and that version works as well.
Besides that, it also opens and filters the FSIW (find symbol in workspace) faster than anything in the newer versions I've been running. Also case=876 (http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=4142) is not present in 1418.
So for the moment I'm going to run 1418 and hope that I don't get a lot of multi cpu issues and slowdowns. |
| Rasmuss |
Posted - Feb 17 2006 : 04:55:10 AM
Feline: I've tried it on a three machines running 1440, and they all exhibit the same behaviour with this exact piece of code.
rhummer/support: Thank you, you are correct, all the functions are indeed listed when I move the opening brace.
But I can't see why this should be an IDE issue. The method list is generated by VA X, and as I wrote it does indeed work flawlessly on my colleagues machines with older versions of VA (VA.NET 7.1.1106 and VA X 10.1.1297.0)
I can understand the context within a method might be wrong due to unmatched braces, but not parsing/listing the rest of the functions is frustrating to me since I rely on the method list for navigating big files. |
| support |
Posted - Feb 17 2006 : 01:11:46 AM
rhummer is correct.
Mismatched braces caused by your #ifdefs confuses the IDE and certainly confuses VA X. With VA X, all code in your #ifdefs is parsed during edit since you are writing/edting all of it. (VA X does not ignore certain #ifdef'd code because you might not #define the guard in the next compile.)
See "Errant Context" at the bottom of:
http://www.wholetomato.com/products/features/context.html?more=yes |
| rhummer |
Posted - Feb 16 2006 : 7:33:56 PM
I had this same issue in a previous thread. This isn't a VAX issue. its actually an IDE issue. In your #ifdef's move the opening { to out side the #ifdef area and things should work fine :) |
| feline |
Posted - Feb 16 2006 : 5:53:26 PM
using VS2003 and VA 1440 i have created a new unnamed cpp file and pasted this code into it, and the alt-m list shows all 4 functions without any edits.
i have also tried pasting this code into the middle of an existing cpp file, and all of the functions, both above and below are listed in the alt-m list.
am i missing something obvious here? is the code in your post the same as the code you tested?
sorry, no progress yet to report on case=876 |
