Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Technical Support
 VA 2393: Incorrect coloring of template types; UE4
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

magratheaa
New Member

USA
4 Posts

Posted - Jan 22 2021 :  05:36:54 AM  Show Profile  Reply with Quote
Hi,

I've been using VAX for a while now, but after recently starting to work with UE4 again, I've been running into a problem with its colorization of some template types. Here's an example:



While if I either turn VAX off or just disable editor coloring, it's colored correctly:



I ran into this issue a few months ago, but before now I was able to work around it by putting this into a header file that was included by just about everything:

#if false

typedef void T;

#endif


However, this no longer works. I really don't want to have to let IntelliSense color the editor, because when working with UE4, it can take up to 10 seconds for it to set colors, but at the same time, the incorrect coloring bothers me even more for whatever reason.
Also, when I mouse over the template type, VAX colors the type in the tooltip correctly. This happens regardless of if T is a class or typename.

Is there any way that I can force VAX to color certain symbols a certain way?

Edited by - magratheaa on Jan 22 2021 05:42:21 AM

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Jan 24 2021 :  08:03:11 AM  Show Profile  Reply with Quote
You could try adding your #if block to a "va_stdafx.h" file, as described here:

https://support.wholetomato.com/default.asp?W302

since this file is parsed first, it might help. I am going to try a couple of tests here.

The basic problem is that the symbol T is already defined inside Unreal Engine, so VA has two different colour rules to apply to the symbol, and since our colouring code is designed to run very quickly, to keep up with scrolling, it can be confused when a single symbol can have more than one colour.

zen is the art of being at one with the two'ness
Go to Top of Page

magratheaa
New Member

USA
4 Posts

Posted - Jan 27 2021 :  9:24:57 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

You could try adding your #if block to a "va_stdafx.h" file, as described here:

https://support.wholetomato.com/default.asp?W302

since this file is parsed first, it might help. I am going to try a couple of tests here.

The basic problem is that the symbol T is already defined inside Unreal Engine, so VA has two different colour rules to apply to the symbol, and since our colouring code is designed to run very quickly, to keep up with scrolling, it can be confused when a single symbol can have more than one colour.



Thanks for your reply! I tried using a "va_stdafx.h" file to the project but it still didn't fix the issue, but I know that I implemented the file correctly because I was able to fix some errors in the UE4 macro coloring.

I tested the following different ways that I thought might fix it:


#if false
typedef void T;
#endif


typedef void T;


class T {};


namespace T {};


namespace T
{
    class T {};
};


Unfortunately none of those worked. If the file is supposed to tell the parser how to color certain symbols, how come it's ignoring it in this case specifically? I looked into the engine source and T was colored correctly in every instance of a templated T. Why is it only being miscolored in my project? As I said in my original post, mousing over the symbol showed the correct color in the tooltip; What would be causing VAX to assign different colors for the editor and tooltips? I would've assumed that it would recognize the symbol was being used as a template, and recolor it when used in that context.

Here's a copy of my "va_sdafx.h" that was able to fix a handful of other symbols:
https://pastebin.com/7nrvJDui

I took a look at the built in header specifically for UE4 and it looks like a few of the macro symbols in there don't match up completely with their definitions in the engine, specifically the namespaces they appear in. I also added a couple entries for FMath, FVector, and TArray methods that were giving me issues.


Edit: I was able to create a macro that can fix the issue for individual files, although this is not the ideal solution and hopefully will only need to be used temporarily:

#define FIX_COLORS namespace T {};

Edited by - magratheaa on Jan 27 2021 10:18:00 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Jan 28 2021 :  05:43:38 AM  Show Profile  Reply with Quote
Unfortunately va_stdafx.h is not designed to fix colouring issues. It can do this sometimes, but it's not what it is there for. VA does not get to "compile" your source code before parsing it, so complex macro and template code can confuse us, since it is a lot easier to make sense of this code by fully expanding it first.

va_stdafx.h is designed to help with this, allowing you to add in project specific help for our parser.

VA's colouring is designed to run quickly, to keep up with scrolling, so when the same symbol, T in this case, can have more than one colour, depending on context, this can confuse our colouring code, resulting in the wrong code being applied some of the time. This is a known limitation, and we do what we can to limit it, but it's a hard problem in general.

Are the other Unreal entries in your va_stdafx.h file to fix colouring problems, or other problems VA is having with Unreal Engine? There are some things in Unreal Engine that do confuse our parser, so I am going to have a closer look at your other entries, since its possible these should be added to new versions of VA.

zen is the art of being at one with the two'ness
Go to Top of Page

magratheaa
New Member

USA
4 Posts

Posted - Jan 28 2021 :  07:16:50 AM  Show Profile  Reply with Quote
quote:
Originally posted by feline

Unfortunately va_stdafx.h is not designed to fix colouring issues. It can do this sometimes, but it's not what it is there for. VA does not get to "compile" your source code before parsing it, so complex macro and template code can confuse us, since it is a lot easier to make sense of this code by fully expanding it first.

va_stdafx.h is designed to help with this, allowing you to add in project specific help for our parser.

VA's colouring is designed to run quickly, to keep up with scrolling, so when the same symbol, T in this case, can have more than one colour, depending on context, this can confuse our colouring code, resulting in the wrong code being applied some of the time. This is a known limitation, and we do what we can to limit it, but it's a hard problem in general.

Are the other Unreal entries in your va_stdafx.h file to fix colouring problems, or other problems VA is having with Unreal Engine? There are some things in Unreal Engine that do confuse our parser, so I am going to have a closer look at your other entries, since its possible these should be added to new versions of VA.



Ah that makes sense, I was just confused why the parser was prioritizing another definition over whatever was in va_stdafx.h. Forgive my ignorance, but would it be possible to have the parser check to see if the "template" symbol is used at the beginning of the line where T is declared (or any template typename), and color it accordingly until the closing "}"?

As for your question, the entries in my va_stdafx.h are mostly to fix coloring issues, but the ones for FMath also help the parser find those methods; it seems to have trouble locating methods inherited from FGenericMathPlatform, as they don't show up in the autocomplete popup. However, the entries that show up only show the basic definition added in the va_stdafx.h, it still doesn't actually find those methods. I could be totally wrong, but reading the built in StdafxUnreal.h leads me to believe that Epic has changed some of the namespaces for macro enums since whenever StdafxUnreal.h was last updated.

Here's a slightly updated version of my va_stdafx.h:
https://pastebin.com/DcVqXL2W

The "namespace T {};" at the end actually does seem to help in some files, but in most it does not. Although, I have found a slightly better workaround macro that is ignored on compile time. Using this macro at the beginning of a file fixes it:

#if true
#define FIX_COLORS
#else
#define FIX_COLORS namespace T {};
#endif

Interestingly, the fix does not carry over into a .cpp file, I don't know if it's something caused by Unreal, if there was a change in VAX, or if it's something to do with my installation, but as I stated in my original post, just putting something similar to that macro's definition in a global header file fixed the issue for any files that included that header, without needing to put anything in the individual files.

Edited by - magratheaa on Jan 28 2021 07:17:15 AM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Jan 28 2021 :  12:49:01 PM  Show Profile  Reply with Quote
Which version of Unreal Engine are you using? I am not finding any obvious sign of the methods FMath::Sign() or FMath::Abs() in Unreal Engine 4.24

I did a search for the two function names in "UnrealMathUtility.h" since VA is not picking up the functions. Am I looking in the wrong file, version of the class, version of Unreal Engine?

There are a few functions that VA manages to miss, so adding them back in like this is something we do, so I am just wondering why I am not seeing these functions here.

As for the colour of T in a template, its a fair question. The colouring code doesn't tend to be that granular. A good example of where you see this is given in the documentation for local symbols in bold: https://docs.wholetomato.com/default.asp?W180

>> Bold is applied without knowledge of context. If foo is defined somewhere in the current file, all occurrences of foo are bold even if they refer to symbols defined elsewhere.

zen is the art of being at one with the two'ness
Go to Top of Page

magratheaa
New Member

USA
4 Posts

Posted - Jan 28 2021 :  6:27:52 PM  Show Profile  Reply with Quote
quote:
Originally posted by feline

Which version of Unreal Engine are you using? I am not finding any obvious sign of the methods FMath::Sign() or FMath::Abs() in Unreal Engine 4.24

I did a search for the two function names in "UnrealMathUtility.h" since VA is not picking up the functions. Am I looking in the wrong file, version of the class, version of Unreal Engine?

There are a few functions that VA manages to miss, so adding them back in like this is something we do, so I am just wondering why I am not seeing these functions here.

As for the colour of T in a template, its a fair question. The colouring code doesn't tend to be that granular. A good example of where you see this is given in the documentation for local symbols in bold: https://docs.wholetomato.com/default.asp?W180

>> Bold is applied without knowledge of context. If foo is defined somewhere in the current file, all occurrences of foo are bold even if they refer to symbols defined elsewhere.



I'm using a self-compiled UE4 2.26. I haven't ever fully redownloaded the source files, but github has kept the source up to date with the official version so I don't think there should be any discrepancy, but I could be wrong. My internet isn't great and it takes me far too long to recompile from scratch to make testing that worthwhile.

Anyway, something odd that I neglected to mention is that VAX does color T correctly, at least until I type the closing ">" of the template argument. Like this:

https://imgur.com/85gImAB
https://imgur.com/5lxxMX8
(for some reason my images were not showing after posting, apologies for the imgur links)

What I really don't understand is why VAX miscolors any use of T in my project, but colors T correctly throughout the UE4 source code. The issue still occurs even if I have 0 includes in the file, it seems as though the parser isn't looking at the included files and is instead looking at the entire solution as a whole, which is weird because I used to be able to coax it into correctly coloring specific symbols with a "#if false ... #endif" in a header that was universally included in every file.

Edited by - magratheaa on Jan 28 2021 6:31:54 PM
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Jan 29 2021 :  10:02:12 AM  Show Profile  Reply with Quote
First the easy bit. When starting a new thread, or using the "Reply to Topic" link, above the quick reply field, you get a row of buttons above the edit field where you type your message. One of these buttons allows you to upload and embed an image in your reply, avoiding the need for external links. Easy when you know where to look, but not so obvious if you are not use to this particular forum.

I have tracked down "Abs" to "FGenericPlatformMath::Abs()", so just working out what is going on here now, since FMath::Abs() does get called by Unreal Engine, but VA isn't listing this as a member function. Thank you for pointing me towards this, this should just work without you needing to use a va_stdafx.h file at your end.

For the colouring of T, it's not always easy to tell why VA is applying the colouring it is, when the same symbol can have more than one "valid" colour. Assuming you have enabled VA's Unreal Engine handling, and it is working correctly, UE code is being treated as a 3rd party library, not part of your solution, which may be a factor.

Also our colouring code is designed to do its best even when your code is "invalid", since you are in the process of writing / editing it, which also complicates matters.

zen is the art of being at one with the two'ness
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
17186 Posts

Posted - Jan 29 2021 :  11:43:43 AM  Show Profile  Reply with Quote
Do you remember what problem you were trying to fix with:

FMath::Sign()
FMath::Abs()

I see where I went wrong looking at this now. I assumed these were "direct" members of the class, rather than inherited members. VA's Find Symbol dialog is only listing direct members, not inherited members, so I was missing these two at first.

But when I use Goto Member on "FMath" or trigger a listbox on an instance of the type "FMath" both functions are showing up correctly. I do see the wrong colour for "Sign" in the goto member dialog, but the right colour once it is entered into the editor.

zen is the art of being at one with the two'ness
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000