Author |
Topic |
|
Nels_P_Olsen
Senior Member
USA
47 Posts |
Posted - Jan 03 2008 : 11:10:35 AM
|
I don't know what the current criteria for a "stable symbol" is, for the "stable symbols in italic" feature, but it is not particularly useful. Wouldn't it make sense for "stable symbol" to be defined as "a symbol that is not defined or overridden in the solution's source files"? Shouldn't that be easy to distinguish when parsing the solution's source files and DLL references?
This would be very useful, as several developers on our team get frustrated when they can't immediately tell if a class or member is "ours" or not, since when debugging, "our" stuff can be stepped into and is more suspect than "stable" code. They want to be able to quickly ignore "stable" stuff when debugging. Their kludge to deal with the issue is to use goofy, unnatural naming conventions to make "our" stuff stick out like a sore thumb when browsing through code. If the "stable symbols in italic" feature worked as suggested, it would satisfy them and eliminate the temptation to use awkward in-house naming conventions ... |
- Nels |
|
feline
Whole Tomato Software
United Kingdom
19015 Posts |
Posted - Jan 04 2008 : 3:21:43 PM
|
A "stable" symbol is any symbol who's definition lives within the stable include directories:
http://www.wholetomato.com/products/features/directories.asp
By the sounds of it you should be able to add the library header files that are causing the confusion to the IDE's list of include directories, so these symbols will start to show up as stable / italic symbols. |
zen is the art of being at one with the two'ness |
|
|
Nels_P_Olsen
Senior Member
USA
47 Posts |
Posted - Jan 25 2008 : 12:19:26 PM
|
We're using C#. A stable symbol for source files in a .NET project should be any symbol defined by DLL references (i.e. not symbols defined in source files in your solution). It's "stable" by definition since you cannot change the symbol's definition (name, type, etc) within your solution. |
- Nels |
|
|
feline
Whole Tomato Software
United Kingdom
19015 Posts |
Posted - Jan 25 2008 : 4:10:32 PM
|
What happens when you have a solution containing two projects, projectA and projectB.
ProjectA builds a dll this dll is added as a reference to ProjectB ?
Are all of the symbols in ProjectA, part of your active solution, now stable?
Generally I like your definition, it makes a lot of sense. I am just wondering about edge cases that might confuse the issue. |
zen is the art of being at one with the two'ness |
|
|
Nels_P_Olsen
Senior Member
USA
47 Posts |
Posted - Feb 20 2008 : 2:25:39 PM
|
In .NET at least, when one project in the solution references something in another project in that same solution, the reference should always be set up as a "project" reference and not a "DLL" reference.
So, in your scenario, the symbols in ProjectA should not be considered stable. This should be easy to distinguish from symbols defined by DLL references. |
- Nels |
|
|
feline
Whole Tomato Software
United Kingdom
19015 Posts |
Posted - Feb 21 2008 : 08:55:04 AM
|
I have checked our documentation, from this page: http://www.wholetomato.com/products/features/italic.asp Which does not tell us much, but we do have:
>> Stable symbols include those defined in imported objects, the System namespace and in headers found using Stable include files in the C/C++ Directories node.
As a simple test I added the line:
Microsoft.IE.SecureFactory foo;
to a C# file in VS2005. Here "Microsoft.IE" is shown in italics. The code does not actually compile though.
Do you have a simple example of where something you have added as a dll reference is not being shown in italics? Is this happening with "standard" dll's, or ones that you have written in house? |
zen is the art of being at one with the two'ness |
|
|
Nels_P_Olsen
Senior Member
USA
47 Posts |
Posted - Mar 05 2008 : 4:26:33 PM
|
OK, it looks like it's trying to italicize stable stuff, but it gets confused on so many symbol names that also appear somewhere in non-stable stuff that half of the stable symbols aren't italicized.
This is a general problem for Visual Assist against C#/.NET because often a symbol doesn't have global uniqueness like in C++. Many properties have the same names as classes. Fragments of one namespace appear in another namespace. This gets Visual Assist confused because it appears to just throw symbols into lists (one list for all symbols that are properties, one list for symbols that are classes, one list for symbols that are pieces of stable namespaces) and assumes that a symbol will never be in more than one list.
So, unless Visual Assist can parse the code more intelligently and take semantics into more consideration, it's going to make the wrong guess too often for a lot of symbol coloring or italicizing to be useful. Even if it's right 80% to 90% of the time, that leaves 10% to 20% as wrongly highlighted. That effectively ruins it. And for my solution, it's not even getting an 80% success rate; it's more like 30% to 40% ... |
- Nels |
|
|
feline
Whole Tomato Software
United Kingdom
19015 Posts |
Posted - Mar 07 2008 : 3:11:40 PM
|
We are working to improve VA's parsing and understanding of C#.
I am not sure if C# allows conditional using statements, but we often run into this effect in C++, which makes resolving what is what very difficult, if not impossible for VA. |
zen is the art of being at one with the two'ness |
|
|
|
Topic |
|