| T O P I C R E V I E W |
| rob8861 |
Posted - Mar 03 2015 : 1:01:37 PM
recently I've been noticing a lot of glitches with the syntax highlighting.
sometimes, a symbol will just not get highlighted and I could not figure out why and how. (it is however, in the list box and tool tip, but not in the editor)
the problem is that the behavior is not consistent and sometimes it happens and sometimes it does not.
is there a way to force VA to re-parse the code and reapply syntax coloring. Turning it on and off does not solve it.
|
| 17 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Mar 23 2015 : 7:06:10 PM
Thank you for the update, it is good to know that we have pinned down what is going on here. I have put in a bug report for "next" being coloured as a function, but as I have said, this is not an easy problem for VA to solve:
case=88660 |
| rob8861 |
Posted - Mar 23 2015 : 08:45:26 AM
i don't think so. I think we have identified the issue here:
c# -> lamda expressions
c++ -> similar symbol definitions (i.e next)
quote:
Originally posted by feline
Knowing this is related to Lambda expressions helps. I have been reading up on them recently, and have reproduced the problem here with C# Lambda parameters not being coloured as local variables:
case=88596
Are you seeing other problems, outside of lambda expressions?
|
| feline |
Posted - Mar 19 2015 : 9:59:23 PM
Knowing this is related to Lambda expressions helps. I have been reading up on them recently, and have reproduced the problem here with C# Lambda parameters not being coloured as local variables:
case=88596
Are you seeing other problems, outside of lambda expressions? |
| rob8861 |
Posted - Mar 19 2015 : 4:25:51 PM
the variables that are not being colored at all are the ones within a lmbda expression. somehow your parser gets confused. not sure why though because it suggests the correct stuff in the list box. it knows the type and the members.
quote:
Originally posted by feline
At least it is not stable for you, that is, in a strange way, good news. Does VA stabilise with the correct colouring, or is VA stabilising with the wrong colouring in this case?
If might be useful to get a copy of your test project if this is quick and easy for you. Please submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up.
I am still not sure if this is relevant to the original problem though, with the variables that are not being coloured at all.
|
| feline |
Posted - Mar 17 2015 : 11:14:45 PM
At least it is not stable for you, that is, in a strange way, good news. Does VA stabilise with the correct colouring, or is VA stabilising with the wrong colouring in this case?
If might be useful to get a copy of your test project if this is quick and easy for you. Please submit the files via the form:
http://www.wholetomato.com/support/contact.asp
including this thread ID or URL in the description, so we can match it up.
I am still not sure if this is relevant to the original problem though, with the variables that are not being coloured at all. |
| rob8861 |
Posted - Mar 17 2015 : 08:40:40 AM
I agree, it is certainly not a stable effect. sometimes it happens, and sometime it does not, which makes it very hard to reproduce.
I can send you the zipped project if you'd like. it is just a test project.
Best, |
| feline |
Posted - Mar 16 2015 : 7:40:57 PM
There are a couple of problems that we run into with the colouring code. Firstly we are applying the colouring behind the IDE's back, so we don't always get to do this in the most logical or orderly manor, since our actions are constrained by what the IDE is doing.
Secondly we don't always have full context when applying the colouring.
I agree, something odd is happening here, since you have two similar lines, but different colouring of next, which is not what I would expect. So far though I am not able to reproduce this reliably. Which is why I asked if this is a reliable and stable effect for you.
Are you seeing this in your main solution, or are you testing this in a simple test project? |
| rob8861 |
Posted - Mar 16 2015 : 3:46:21 PM
i don't think it is. if you look closely at these two statements:
temp->next = nullptr; // VA knows it is a local variable declared in the Node struct, so it assigns the correct color
last->next = temp; // for some reason VA thinks this instance of next belongs to the stable which is defined as a function?
I am not sure which variables are not colored. in the screen shot I sent you all the variables are colored. only the next pointer is sometimes colored like a method.
i guess as long as the symbol is not a reserved keyword then, VA should always look if a symbol is declared locally and if it is, uses that to determine the coloring. |
| feline |
Posted - Mar 14 2015 : 12:40:46 AM
Is this colouring problem with "next" stable? I am seeing the same effect with this struct, but only briefly, and then VA catches up and uses the correct colouring.
For me "next" is occasionally shown in italics, VA is remembering that this is a known function name from the stable include directories. So it is not a function in your solution, but it is known as a function by VA.
However this does not give any insight into why you are seeing variables that are not coloured at all.
It is possible to confuse our colouring code, but this is normally due to the symbol name being used for different things in different places, so it has the wrong colouring, rather than no colouring at all. |
| rob8861 |
Posted - Mar 13 2015 : 11:33:16 PM
Hi,
I am going to reopen this issue because I've encountered it again. this time while working in c++. At this point I believe there is a glitch in the syntax coloring feature for both c++ and c#.
please see attached screenshots. it is a very simple file with no fancy c++ stuff.
|
| feline |
Posted - Mar 06 2015 : 11:59:29 AM
Well unless it is some form of cascade error, prompted by something further up the file, we can probably ignore lambda for now as a trigger.
Something further up the file is a possibility though. Next time you spot an example of this effect, can you please try copy and pasting a sensible block of code into a new file, and see what happens to the colouring then? Obviously if you don't copy the declaration for the local variable that won't help.
Do you get this problem with longer variable names, or just single letter variable names? I am still searching for any form of pattern or clue here.
As for learning something about lambda's, it is on the list, I am just not sure when I will get there. I bounce around a lot, a bit of this, a bit of that, so don't always study things in great depth  |
| rob8861 |
Posted - Mar 06 2015 : 10:18:09 AM
quote:
Originally posted by feline
You are using => which is not an operator I recognise. Typing in a simple test function into VS2013, C#, I am getting an error about lambda expressions and type converting.
So I am assuming this is C# Lambda code. Are you seeing this problem outside of lambda code, or so far only inside lambda code? It looks like I need to try and learn something about lambda code
I have seen it mostly in non lambda code. it just happened that I noticed it in a lambda expression :).
p.s: you should learn about it. it is one of the best features in c#. I read that c++11 borrowed the idea but i find the c# syntax much easier to understand :) |
| feline |
Posted - Mar 05 2015 : 11:36:26 AM
You are using => which is not an operator I recognise. Typing in a simple test function into VS2013, C#, I am getting an error about lambda expressions and type converting.
So I am assuming this is C# Lambda code. Are you seeing this problem outside of lambda code, or so far only inside lambda code? It looks like I need to try and learn something about lambda code |
| rob8861 |
Posted - Mar 05 2015 : 08:27:23 AM
This morning when I worked on my c# project I noticed the behavior again. I attached a screen shot.
so far i was not successful in replicating it in c++ but when it happens i will try to capture it.
regarding the usage of local and function vars with the same name. i usually try to avoid that but i will pay attention and see if this might cause the discoloration issue.
p.s: running Tool -> reparse file did not fix the issue.
|
| feline |
Posted - Mar 04 2015 : 2:38:55 PM
If the effect is stable then it could be something confusing our parser, or it could be related to duplicate symbol names. Sometimes, if the same symbol name is used for two different things, our colouring code can get confused, since it has to run quickly to keep up with things. So here if you have functions and local variables with the same name this might be a factor. |
| rob8861 |
Posted - Mar 04 2015 : 12:50:52 PM
I haven't paid attention to where exactly it happened. I want to say in both but I will double check.
I tried closing the file, or even closing the project or restarting visual studio. Neither helped.
the only thing I haven't tried yet was Tool -> Reparse file.
the other weird thing I noticed is that some fields will be colorized while others will not. for example, let's say I have an object Object1 with field1, filed2 and field3.
Object1.field1 <- colorized
Object2.field2 <- not colorized in editor but tooltip and list box are fine
Object3.field3 <- colorized
I will try to take screen shots and certainly update you on whether the reparse fixes the issue.
Best,
|
| feline |
Posted - Mar 04 2015 : 12:22:46 AM
You can force a reparse by using the command:
VAssistX -> Tools -> Reparse Current File
normally you should never have to do this though.
When you are seeing this problem, are the symbols being used inside a function body, or are you seeing this problem on a declaration / implementation? Or both?
When you see this happen, if you close and reload the file, do you still have the same problem? I am wondering how stable this problem is, since that might give us a clue. Also does triggering the reparse make any difference? |
