| Author |
 Topic  |
|
|
draza
Senior Member
France
48 Posts |
 Posted - Nov 17 2004 : 02:23:20 AM
|
Usual suspects:
1.
using System.Collections;
using System.Runtime.Serialization;
In both cases, until "full" parser runs (a good few seconds after I click into the editor window) the LAST part of the statement is colored as a member and not as a type/namespace. Then, the second line looks fine, but the first does not.
2.
VA.X is still confused to see properties with the same name as a type (from BCL). In my scenario, I have a property I called Buffer, which is colored as type when used as a property and colored as property when used as a type :(
3.
I see one case where a member function is colored as type, but there is nothing special about it - since it's only one place (for now) I can more or less ignore it for now.
|
This problem when solved will be simple |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Nov 18 2004 : 5:00:35 PM
|
point 1 - is this the first time you have loaded this cs file? i am guessing you have a reasonable size project. if so, this is normal. VAX doesn't start to apply its additional syntax highlighting until it has finished the full parse, since until it has it doesn't know what colour to make the words  until VAX gets there you are stuck with the IDE syntax highlighting.
i see this effect at work, and it can take a couple of minutes before files are syntax highlighted when i first load the IDE and our main project.
points 2 and 3, i don't really know any C#, so if you can post some example code and explain what i am looking at i will try to reproduce the effect. |
zen is the art of being at one with the two'ness |
 |
|
|
draza
Senior Member
France
48 Posts |
Posted - Nov 19 2004 : 02:11:49 AM
|
quote:
Originally posted by feline
point 1 - is this the first time you have loaded this cs file? i am guessing you have a reasonable size project. if so, this is normal. VAX doesn't start to apply its additional syntax highlighting until it has finished the full parse, since until it has it doesn't know what colour to make the words until VAX gets there you are stuck with the IDE syntax highlighting.
i see this effect at work, and it can take a couple of minutes before files are syntax highlighted when i first load the IDE and our main project.
points 2 and 3, i don't really know any C#, so if you can post some example code and explain what i am looking at i will try to reproduce the effect.
1. No, it's not until full parse is finished that I am trying to judge the coloring. Moreover, once the full parse is done, files are not colored until I click inside the editor window, and then, few seconds later, I can see some elements being correctly color-coded (most notably methods). I inquired about this delay several times BTW and never got any (let alone satisfying) answer [this is like point 1b, not directly related to my original question but to your question :)]. Note that using statements with 3 levels of nesting (System.Something.MoreNames) are colored correctly but names with 2 levels like System.SecondLevel are not (might hint as to where the problem lies). This is consistent across the files.
2. Say you have something like this:
class Test
{
private Byte[] _buffer;
public Byte[] Buffer
{ get { return _buffer; } }
// ,,,
}
// somewhere else in your code
Test t = new Test();
Byte[] buff = t.Buffer; // this line is problematic
The last line will have "Buffer" colored as a type. The reason for this is I guess that there is a type called Buffer (it's System.Buffer, derives directly from System.Object) and VA does not see the context correctly (in the expression above, I don't see any way Buffer could be interpreted as a type).
3. A class called BitArray (System.Collections.BitArray) has members called "Set" and "Get". They are both colored as types on the places where I call them and not as methods. I had one method called "Stop" on one of my classes that consistently would exhibit the same kind of behavior. I am guessing that "Set" and "Get" due to ignored casing might get colored wrong (there are keywords "get" and "set" in C#) and I have no idea about "Stop" but when I renamed the function the problem went away - go figure.
Regards,
Drazen |
This problem when solved will be simple |
Edited by - draza on Nov 19 2004 02:14:36 AM |
|
|
|
Stephen
Tomato Guru
United Kingdom
781 Posts |
Posted - Nov 19 2004 : 04:06:51 AM
|
2 is because the colouring algorithm is dumb, so as to be fast when you're typing and scrolling. If the same name occurs as two different types, the colouring can't tell between them.
This is becoming a FAQ. There was a long discussion about it last week in thread 3214, and another thread in the private forum (3216). The fact that it's a FAQ suggests that it's annoying a lot of people a lot of the time. On the other hand, I imagine that the limitation is due to a fundamental design decision which would be hard to change, even if there were no performance implications with a smarter approach. |
Stephen Turner
ClickTracks http://www.clicktracks.com/
Winner: ClickZ's Best Web Analytics Tool 2003 & 2004
|
|
|
|
draza
Senior Member
France
48 Posts |
Posted - Nov 22 2004 : 02:36:58 AM
|
quote:
Originally posted by Stephen
2 is because the colouring algorithm is dumb, so as to be fast when you're typing and scrolling. If the same name occurs as two different types, the colouring can't tell between them.
This is becoming a FAQ. There was a long discussion about it last week in thread 3214, and another thread in the private forum (3216). The fact that it's a FAQ suggests that it's annoying a lot of people a lot of the time. On the other hand, I imagine that the limitation is due to a fundamental design decision which would be hard to change, even if there were no performance implications with a smarter approach.
Let me quote the boss from "Office Space" ;) "I'm gonna have to go ahead and..." slightly disagree :)
I know the "fast parsing" algorithm is dumb, but note what that algorithm already knows to do - disambiguate types, local variables/parameters and methods (normal and constructors). Thus it is not THAT dumb :)
Now look at my example - on the last line, Buffer is clearly not a type. It might be confused with a method, but not with a type. Same goes for 3 - Set and Get are methods just like any other method.
What I'm trying to say is that context (of which VA code is aware) should be more important than simple text match, and it is normally, except in these few cases. That's why I would classify these as "fixable bugs". Of course, not seeing the code and design I cannot claim that, but until I get a definitive "no" from support I won't give up hope :) |
This problem when solved will be simple |
|
|
| |
Topic |
|
|
|
Topic Locked
