| Author |
 Topic  |
|
|
CliffyP
Ketchup Master
56 Posts |
 Posted - May 14 2019 : 11:36:43 AM
|
See picture:
First time I have seen this happen, but it is at least reproable on this symbol. |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - May 15 2019 : 10:18:00 AM
|
| Very strange. I am seeing the same effect here. Just to double check, are you seeing any syntax colouring problems in the cpp file, for line 301? I am not, it is only showing up in the Find References Results window here. |
zen is the art of being at one with the two'ness |
 |
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - May 15 2019 : 11:30:34 AM
|
I have managed to simplify this right down, its not due to Unreal, its just somehow triggered by one of the string parameters. Really surprising, but there we go. I have put in a bug report for this:
case=140343
So you are unlikely to run across this to often, but if you do, I would be interested to know about it  |
zen is the art of being at one with the two'ness |
|
|
|
CliffyP
Ketchup Master
56 Posts |
Posted - May 17 2019 : 2:33:40 PM
|
Found another case:
Actually there are two problems in the coloring, the one specific to the find references is that exclamation point in front of OpacityMask.
The other problem with the coloring is incorrectly colorizing OpacityMask as a define/macro when it is actually a member variable and is supposed to be colored teal. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - May 20 2019 : 11:40:37 AM
|
Definitely a situation where drawing arrows on the screen shot to point at the points of interest would have helped
I am seeing the bug with the ! being coloured the same as the symbol it is pressed up against, and I have put in a bug report for this:
case=140445
I suspect I have never noticed this before since the colour difference is not that obvious in my normal colour scheme.
No sign of OpacityMask being coloured as a macro though. Which version of Unreal Engine are you working with? I have just installed UE 4.22.1, in case it was due to a change since UE 4.20, which I already had installed, but I am still not seeing the problem.
If you open VA's Find Symbol dialog and filter on ".OpacityMask.", to get a whole word match, what results show up?
Doing this test here, in a new, default Puzzle project created with UE 4.22 I am seeing 3 results only, when I turn Off:
Find Symbol dialog -> Only classes, structs & namespaces
all three are inside my UE stable include directories. Two are variables and one is an enum. Which is where the problem is probably starting to come from. The same symbol is both a variable and an enum, so it's not always clear to VA which colour it should be given, especially since our syntax highlighting code has to run very quickly to keep up with scrolling and moving through your code.
Still, I am not sure why I am seeing a different result to you. |
zen is the art of being at one with the two'ness |
|
|
|
CliffyP
Ketchup Master
56 Posts |
Posted - May 28 2019 : 2:44:43 PM
|
Im on a custom engine version, it is at parity with 4.22.1 though.
Now that I think about it, I also see other types of coloring errors.
For example a bad one is coloring local variables as functions, which can happen when using initilization constructor, like this:
MyType MyVal(Something);
So instead of the variable color (blue), it ends up being the function color (orange).
I also see member vars that are a generic name sort of unable to decide what color they should be.
Something like this:
MyVal.Value;
Where Value is colorized as either a type (yellow), or a define/macro (purple) most of the time instead of what it should be (blue).
Frankly it has been like this since I started using VAX, but I just got used to it I guess. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - May 29 2019 : 3:08:31 PM
|
Unfortunately these are known problems / side effects of the way VA does syntax colouring. We do a "quick and fairly good" approach, rather than a "slow, it will happen when we get there, but accurate" approach. This is documented at the end of this page:
https://docs.wholetomato.com/default.asp?W179
Not always ideal, and we do work to try and improve the colouring behaviour in VA. Since this is normally only a problem in known and well defined cases, it's not to difficult to spot and work around mentally. |
zen is the art of being at one with the two'ness |
|
|
|
Zeblote
Tomato Guru
183 Posts |
Posted - Jun 16 2019 : 8:52:14 PM
|
Is there no way to improve that heuristic a bit without guaranteeing accuracy? For example, no symbol after a . or -> should ever be colored as a type, it simply makes no sense.
So if it isn't clear whether to use type or variable coloring, it seems to me (I don't know how exactly this works, of course) that it would be easy to quickly check if there is a . or a -> directly in front of the symbol and use the option that isn't type color then. |
Edited by - Zeblote on Jun 16 2019 8:54:53 PM |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jun 17 2019 : 08:04:57 AM
|
If we assume VA has full control over the code in the editor window, and can colour the code in an order that makes sense, then this works and makes some sense. Unfortunately we don't have full and sole control over the editor, we are working with and sometimes around the IDE, which limits and controls what we can do, and how we can do it.
There is also the question of performance. Our colouring code is designed to run quickly, so that it keeps up with code scrolling. As a result we try to balance complexity with speed. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
|
| |
Topic |
|
Find Reference Syntax Coloring bug
