Fixed! See here to reset visual studio project, which fixed it for me
Hey guys!
I’ve been following every tutorial on the world wide web on how to get c++ and umg working.
Here’s what I’ve done:
Did the whole “PublicDependencyModuleNames.AddRange(new string] { “Core”, “CoreUObject”, “Engine”, “InputCore”, “UMG”, “Slate”, “SlateCore” });” thing
Added all these to the project header: #include “Runtime/UMG/Public/UMG.h” #include “Runtime/UMG/Public/UMGStyle.h” #include “Runtime/UMG/Public/Slate/SObjectWidget.h” #include “Runtime/UMG/Public/IUMGModule.h” #include “Runtime/UMG/Public/Blueprint/UserWidget.h”
swung a dead cat chanting rhymes
After doing just this, everything runs. However… when I added a child class of UUserWidget, it all crashed down on me.
Basically, the engine cannot find anything beyond the “UMG/Public” folder. Anything else, such as #include “Anchors.h”, (which is found in the slate folder) cannot be registered:
What is the actual error you’re getting? All your image shows is intellisense lookup failures, which happens all the time and doesn’t mean there’s any issue with the code.
This looks like something that defines public/private folders! But UMG doesn’t have this!
Could this be the problem? If so, why am I the only one with this problem? ;_;
I’m afraid I am being very confusing.
Here’s what’s happening.
In the UMG.h, or any other header dealing with the UMG module, it has includes such as this: #include “Anchors.h”
However, Visual Studio cannot find this file. HOWEVER If I edit the header to become this: #include “Slate/Anchors.h”
It works. Basically, Visual Studio cannot understand that there are headers within the “Slate” directory, and all the other directories like it.
I cannot edit every single include, because each include contains more includes, and such… way too many to fix.
In other words, from what I can see every module has a list of directories to search headers for. UMG doesn’t seem to have it, for me at least.
Core does seem to have it. It looks like “PublicIncludePaths.AddRange” has something to do with this.
The actual error message doesn’t do anything exciting, other than the fact that it cannot find the headers. Here’s a little example:
Error: Cannot find source file "Anchors.h"
And about the ommitting, the part I put the "#include “Runtime/UMG/Public/UMG.h” is within the project header, which everyone says to do. This part works, since it puts these files into the external dependencies folder
Okay, I’m not really sure what’s wrong. Unreal Build Tool is set up such that anything below the Public subdirectory will be found automatically without it being necessary to provide the full file path. So the fact the UMG module doesn’t specify the include paths shouldn’t be an issue.
Still a bit confused by your error message though. That came directly from the VS build output? I’ve never seen it worded that way. If you post up the entire build output, it might shed a bit more light on what’s happening.
You need to include the UMG path in your PublicIncludePaths in *.Build.cs file. After that, you should be able to include headers files in your project as usual.
As I understood it, by including a module in the public dependencies, the public include paths are set up automatically. I’ve never explicitly specified include paths for engine modules and haven’t had any problems.
If you could, please, elaborate on what exactly all these specifiers do, that would be great.
My understanding is:
PublicIncludePaths is to allow including .h files from the **specified **module’s Public folders inside of this module’s Public folders. But since UHT parses these folders anyways you don’t really have to use this option.
*PrivateIncludePaths *is to allow including .h files from the **specified **module’s Private folders inside of this module’s Private folders, e.g. PCH header file. For instance, if I have the following folder structure:
I now **can **include my SomeModulePCH.h file (because it is inside of the root Private folder, which we’ve included) inside of my Private folders, but can not include the SomeModuleOther.h since it’s in Private/Other folder which was not added to PrivateIncludePaths.
PublicDependencyModuleNames specifies modules that your** project’s or module’s Public code depends on, meaning you can include Public headers from the specified modules inside your project’s or module’s **Public **folder. It is a must when you create a new class object that inherits from objects in other modules. The most common example is UObject classes (which covers a good deal of use cases). This is why there used to be the Classes folder in the past, I guess. For instance, if I have the following folder structure:
Now I can include any header file from the SomeModule’s Public folder (including sub-folders) inside of my project’s Public folder.
*PrivateDependencyModuleNames *specifies modules that your project’s or module’s Private code depends on, meaning you can include Public headers from the specified modules inside your project’s or module’s **Private **folder. You might use this when you have an interface header file in your Public folder and it’s implementation from the Private folder has several external dependencies, but the interface itself does not need to know or care about them.
If I add this code to MyProject.Build.cs:
PrivateDependencyModuleNames.Add( "SomeModule" }
Now I can include any header file from the SomeModule’s Public folder (including sub-folders) inside of my project’s Private folder.
And in general, you can not include headers from the Private folder inside of the Public folder.
Please, correct me if I am wrong. This is a tricky topic and I would love to hear the explanation from someone at Epic.
This tutorial should have you up and running in no time. I’ve also just tested adding a simple test UCLASS that extends UUserWidget in my local copy of that tutorial, and it compiled without issue. If it doesn’t work, please reply and we’ll figure out what’s going on in your project.
@: I have indeed done this, as I have followed the tutorials online @Lauren Ridge: I’ve tried this, and it didn’t work @Richard Hinckley: I have followed this and every other tutorial I could find, no dice :c
It looks like this could be some sort of problem with my project specifically, (visual studio, probably not ue4) somehow… something is broken in my project, for some reason! Atm I’m even more stuck due to this seemingly unrelated problem here: Cannot open input file 'HACD_64.lib' ;_; - C++ - Epic Developer Community Forums (If anyone knows how to fix this, I’d be happy happy xD)
I may have to be forced to create a new project and transfer stuff, which sounds very very scary… I’ve been working on this project for many months ;_; This whole thing is making me very depressed, I wanna code!
EDIT: I’ve noticed something new with my project: Inside the external dependencies, there’s A LOT of files… like, every single file in the entire ue4 engine. A thousand? This is new, anyone know why this is? This could be a reason.
EDIT AGAIN: In the .vcxproj file, I found a list of directories, and boom! The UMG files are indeed in there. In other words, looks like… I have to make a new project. This really sucks.
Thank you for working through this and posting the solution. I had the exact same issue. I went through the C++ UMG tutorial and everything worked perfectly. Then I added the same code to my existing project and it had the issues you were having.
Following your three steps fixed the issue. I now know to not trust the build system.
Ideally the “Refresh Visual Studio Project” command within UE4 or a similar command would do all of this for you. This is the second place I saw instructions on manually clearing out files in your UE4 folder structure to clear issues.
Does anyone know if there is a tool that will “clean” a UE4 project to fix any issues that can be introduced through tooling failures?