| Author |
 Topic  |
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
 Posted - Aug 24 2006 : 08:26:35 AM
|
I don't know what happened between builds 1530 and 1532, but the last one is IMHO the least successful version I encountered in the last 2 years since my company started using visual assist.
I don't even want to talk about the refactoring that isn't working (function signature changed only in .h file but not in .cpp) or that a simple renaming of a variable causes VaX to announce that it can't be done.
It's the good old features that are broken: syntax highlighting selectively marks class names as local variables or it changes (only at display, not in the saved file) O to 0, other functions and variables are suddenly marked as unrecognized...
VA view shows (sometimes) irelevant info when hovering variables, and the situation with ALG+G isn't much better.
I'm aware that this is still a beta build, but I was surprised to see on somewhere on your site that this build is close to the final.
VA_X.dll file version 10.3.1532.0 built 2006.08.10
Licensed to:
VA X: algotec.co.il (25-user license) Support ends 2007.05.15
VA.NET 7.1: algotec.co.il (5-user license)
VAOpsWin.dll version 1.3.3.6
VATE.dll version 1.0.5.8
DevEnv.exe version 7.10.3077.0
msenv.dll version 7.10.6015.0
Font: Courier New 13(Pixels)
Comctl32.dll version 5.81.4916.400
Windows 2000 5.0 Build 2195 Service Pack 4
Single processor
Platform: Win32
Stable Includes:
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\include;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\include;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include\\prerelease;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\PlatformSDK\\include;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\SDK\\v1.1\\include;
D:\\DXSDK\\include;
S:\\jdk1.4\\include;
S:\\jdk1.4\\include\\win32;
D:\\DEV\\INC\\UNIX;
Library Includes:
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\mfc;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\atlmfc\\src\\atl;
D:\\Program Files\\Microsoft Visual Studio .NET 2003\\Vc7\\crt\\src;
Other Includes:
|
|
|
rhummer
Tomato Guru
USA
527 Posts |
Posted - Aug 24 2006 : 08:51:18 AM
|
| Have you tried to rebuild the symbol database? That is usually the first thing I try if I see things being weird. |
Tools Engineer - Raven Software
VS2005 SP2/VS2008 SP1 - VAX <LATEST> - Win 7 x64
|
 |
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Aug 24 2006 : 1:43:46 PM
|
VA X is obviously whacked in your environment. We suspect one item is the culprit to all of your problems.
Can you try reinstalling (which forces the rebuild rhummer suggests)?
Do your coworkers have the same problem?
Any other add-ins installed? (We suspect not since you've had success previously)
Anything recent change in the installation/setup of your IDE(s)? |
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Aug 27 2006 : 12:53:38 PM
|
I tried to rebuild symbols, but it had no effect.
Tried reinstalling build 1532, but still nothing... 
Besides Visual Assist I also have the following add-ins:
Compuware DevPartner, Incredibuild and the Intel compiler.
After reading your question I recalled that indeed there is another "recent change", I uninstalled the visual studio 2003 and reinstalled it a few days ago, (I intended to install the VS2003 SP1 but the installation failed due to a hotfix we had to install some time ago, anyway I did not install yet the SP).
I am not aware of other developers here using VaX versions newer than the latest released version, so I cannot compare if my problem is reproducible. |
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Aug 28 2006 : 09:48:57 AM
|
Unfortunately build 1533 didn't bring any improvement over 1532.
You mentioned that you have culprit to all of my problems, is there any advancement in finding it ?
I observed that the cases where the variable type is not highlighted are when the variable is a pointer. Simply removing the "*" from the variable declaration brings back the correct highlighting. (the problem does not reproduce with all pointer declarations, some are OK).
Still no clue about the other problems. |
Edited by - dodudo7 on Aug 28 2006 10:12:25 AM |
|
|
|
rhummer
Tomato Guru
USA
527 Posts |
Posted - Aug 28 2006 : 10:40:26 AM
|
Is there anything different about the coding style you have in the files you are working with? There is a bug reproded by a user that having his code formated like so:
nt MyClass :: MyFunc() // fails
int MyClass ::MyFunc() // fails
causes the parser to not recognize symbols and causes issue. Might you have some *odd* coding style in the code base?
Just thinking out loud trying to see whats up, as I've been using 1532 and 1533 before they were released and they are fine. |
Tools Engineer - Raven Software
VS2005 SP2/VS2008 SP1 - VAX <LATEST> - Win 7 x64
|
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Aug 28 2006 : 2:33:56 PM
|
This was a pretty good guess!
Indeed some of our old code base (written around 1994) is using the coding style you mentioned.
Interestingly, most symbols that are incorectly highlighted (bold gray as local variable instead of blue as class name), are recognized. I use the default syntax coloring. I tried replacing all MyClass :: Myfunc() to MyClass::Myfunc() for one of the classes that is creating the problem but it didn't help. Yet, this coding style is not new, and Visual Assist didn't complain about it until now.
Also in other scenarios incorrect syntax highlighting is for correctly recognized types/variables. Unrecognized code is not highlighted at all.
I am attaching two snapshots of code, maybe it can help, the first one is correctly highlighted but unfortunately it won't compile as the returned type is a pointer.
The second is using a pointer but is incorrectly highlighted.
Any idea what can be the problem?
|
|
|
|
rhummer
Tomato Guru
USA
527 Posts |
Posted - Aug 28 2006 : 3:08:29 PM
|
Well that bug is new to the 15xx builds :)
out of curiousity what happens if you change:
Dicom_SQ* modified_attributes to:
Dicom_SQ *modified_attributes
Does it still show incorrectly or is it correct? |
Tools Engineer - Raven Software
VS2005 SP2/VS2008 SP1 - VAX <LATEST> - Win 7 x64
|
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Aug 28 2006 : 3:57:39 PM
|
does this only effect some classes? this seems to be what you are saying.
when this happens, what happens if you try alt-g on Dicom_SQ ?
is the header for this class included in your solution? is it listed in OFIW?
is it located in a stable include directory?
what happens if you create an instance of Dicom_SQ in a new, empty cpp file? it is possible there is something further up the current cpp file that is causing this effect.
if you get the same colouring effect in a new, blank cpp file is it possible to get a copy of the header file for this class? often this is impossible, but it is worth asking. |
zen is the art of being at one with the two'ness |
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Aug 29 2006 : 07:39:45 AM
|
Both Dicom_SQ* modified_attributes and
Dicom_SQ *modified_attributes or even
Dicom_SQ * modified_attributes are incorrectly colored.
The header file is included in the solution and alt-g works OK. It is not located under the stable directories.
Your assumption is correct, not all classes are affected, actually even this specific class is highlighted correctly in part of the solution files, while in the rest of the files it is not.
Both .C and .h files appear in OFIW.
I tried, as you suggested, creating an instance in a new empty file and it was highlighted correctly. I tend to believe that indeed something in the .cpp file is creating the problems. I will play a little bit more with the cpp file and I'll keep you updated if I'll find anything. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 02 2006 : 12:55:25 PM
|
you may want to try the following test then. make a copy of this problem cpp file, and if it shows the same issue, simply delete code from the file one chunk at a time.
by using something similar to a binary chop you should be able to quite quickly and easily reduce the file right down, while still keeping this colouring problem.
hopefully you will be able to get the file down to such a short, and meaningless piece of code that you will be able to post it. |
zen is the art of being at one with the two'ness |
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Sep 03 2006 : 1:40:25 PM
|
I found something!
The code that is causing a coloring problem is easily reproducible on a small scale project:
const CMyClass* c = dynamic_cast<const CMyClass*>(object);
This line causes references of CMyClass* to be colored as local variables instead of class name.
If you'll remove the const:
const CMyClass* c = dynamic_cast<const CMyClass*>(object);
the class name will be colored correctly. 
I still have another problem with some class member variables that are colored as if they were local variables. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 03 2006 : 5:18:45 PM
|
got it!
case=2352
strangely several of my tests had no problem with this dynamic_cast, but if i use a class defined in the header file then it goes wrong, exactly as you describe. thank you for the clear description
the class member variables, do you tend to have local variables with the same name as the class member variables? i am not sure what might trigger this, but duplicate names confusing the colouring code is possible. |
zen is the art of being at one with the two'ness |
|
|
|
dodudo7
Ketchup Master
Israel
55 Posts |
Posted - Sep 04 2006 : 06:25:17 AM
|
Usually, I refrain from using local variables with same name as class members. It's bad coding practice, makes the code less readable and more difficult to debug... BUT...
You were correct in your assumption, indeed I have a local variable, (actually it's a parameter of another method from the same .cpp file and class) that has the same name as the class member. The highlighting was incorrect in other methods where only the class member variable is defined.
Again, this issue is also easily reproducible on small scale projects. |
Edited by - dodudo7 on Sep 04 2006 08:56:08 AM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19021 Posts |
Posted - Sep 04 2006 : 6:01:29 PM
|
yes, setting up this test i see the same problem. the VA colouring code has to run very fast, in order to colour code in real time as you scroll up and down the window. as a result it is possible to confuse it, as this shows.
i have put in a case so we are aware of this, but this is unlikely to be addressed soon since it is likely to be quite hard to solve, given the speed of the code, and the limited information it has to operate on.
case=2364 |
zen is the art of being at one with the two'ness |
|
|
|
support
Whole Tomato Software
5566 Posts |
Posted - Jul 14 2008 : 2:52:55 PM
|
| case=2352 is fixed in build 1645 |
Whole Tomato Software, Inc. |
|
|
| |
Topic |
|
1532: unusable version
