#jira UE-4770 - LIVE: Users are able to name a new class "Platform" even though there is already a class by that name in the Engine.
[CL 2357149 by Richard TalbotWatkin in Main branch]
* Moved Slate.h into SlateBasics.h and began shifting less commonly used headers into SlateExtras.h.
* Slate.h now simply includes SlateBasics.h and SlateExtras.h.
* Slate.h includes a deprecated warning now to indicate that SlateBasics.h + specific includes should be used instead.
* Moved dozens of inlined functions using Slate widgets into .cpp files to avoid header dependencies.
* All code samples now include SlateBasics.h and SlateExtras.h so future shifts will not break most those projects, but not trigger the deprecation warning of including Slate.h.
#BUN
[CL 2329610 by Wes Hunt in Main branch]
TTP# 342920 - EDITOR: Cloned C++ projects do not compile correctly
TTP# 342762 - Editor: Feature Request: Relax the restrictions on what game modules can have new classes created within them
This has allowed the validation logic to be simplified, as it pushes the responsibility onto the user to say which module they want their new class to go into, rather than relying on the validation logic to correctly infer which module the class should be going into.
This also relaxes the previous naming restrictions due to assumptions about module names, as you're now able to add code to any module listed in your .uproject file.
I've tested:
- Adding code to a normal project.
- Adding code to a cloned project.
- Creating a new code based project.
- Adding code to an empty/blueprint based project.
All of these cases generated code which compiled correctly.
#codereview Ben.Marsh, Max.Preussner
[CL 2242790 by Jamie Dale in Main branch]
If the module is inside the Public or Classes folder, it is included directly (since all these folders are on the include path), otherwise it's included relative to the module source root (which is now on the include paths due to a recent UBT change).
ReviewedBy Ben.Donatelli
[CL 2109096 by Jamie Dale in Main branch]
This now uses GameProjectUtils::GetCurrentModuleContextInfo(), which provides the same information as used by the rest of the class wizard validation.
ReviewedBy Thomas.Sarkanen
#codereview Max.Preussner
[CL 2088202 by Jamie Dale in Main branch]
TTP# 332794 - EDITOR: Usability improvements for the New Class Wizard
GetClassLocation was failing because it was doing the validation based upon the current project, and not the project that was being created. I've changed the validation logic and creation functions to use a module context that must be provided; this allows the functions used to generate code for a new project to override the module validation information.
[CL 2075544 by Jamie Dale in Main branch]
TTP# 332794 - EDITOR: Usability improvements for the New Class Wizard
Abstracted away the parent class information into FNewClassInfo, which can hold either a UClass*, or an enum value corresponding to a pre-defined non-UObject type class (currently; an empty class, a Slate widget, and a Slate widget style).
Made the interface of GenerateClassHeaderFile and GenerateClassCPPFile more consistent. They now both take an unprefixed class name as well as the base class information; any extra information they can then generate internally. They also no longer rely on the filename to work out the class name, as the Slate classes may add a prefix or suffix to the filename due to the way the templates are set-up.
Updated everything in the SNewClassDialog and GameProjectUtils that was previously working with a UClass* to work with a FNewClassInfo instead.
ReviewedBy Thomas.Sarkanen, Max.Preussner
[CL 2075367 by Jamie Dale in Main branch]
