4.6 Preview OnMouseEnter crash on UMG widget which is loading screen


I tried to implement a loading screen as follows:

FLoadingScreenAttributes LoadingScreen;

	LoadingScreen.bAutoCompleteWhenLoadingCompletes = true;
	TSharedPtr< SWidget> LoadingScreenSlateWidget = LoadingScreenWidget->TakeWidget();
	FString str = FString(TEXT("Lol"));
	LoadingScreen.WidgetLoadingScreen = LoadingScreenSlateWidget;//FLoadingScreenAttributes::NewTestLoadingScreenWidget(); // <-- test screen that comes with UE


The problem is when the player moves the mouse cursor when I call this function the game crashes with this error message:

 Unknown exception - code 00000001 (first/second  not available)
 Assertion failed: !GIsRoutingPostLoad [File:D:\BuildFarm\buildmachine_++depot+UE4-Releases+4.6\Engine\Source\Runtime\CoreUObject\Private\UObject\ScriptCore.cpp] [Line: 799] 
 Cannot call UnrealScript (Test_C //Engine//Transient.GameEngine_0:GameInst
 KERNELBASE + 24684 bytes
 MyProject!FOutputDeviceWindowsError::Serialize() + 261 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\core\private\windows\windowsplatformoutputdevices.cpp:95]
 MyProject!FOutputDevice::Logf__VA() + 248 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\core\private\misc\outputdevice.cpp:144]
 MyProject!FDebug::AssertFailed() + 1221 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\core\private\misc\outputdevice.cpp:224]
 MyProject!UObject::ProcessEvent() + 343 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\coreuobject\private\uobject\scriptcore.cpp:799]
 MyProject!UUserWidget::OnMouseMove() + 255 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\intermediate\build\win64\inc\umg\umg.generated.cpp:868]
 MyProject!SObjectWidget::OnMouseMove() + 103 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\umg\private\slate\sobjectwidget.cpp:175]
 MyProject!<lambda_988307d939d72f95a562170c60c3814f>::operator()() + 568 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:4230]
 MyProject!FEventRouter::Route<FReply,FEventRouter::FBubblePolicy,FPointerEvent,<lambda_988307d939d72f95a562170c60c3814f> >() + 464 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:208]
 MyProject!FSlateApplication::ProcessMouseMoveEvent() + 4300 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:4236]
 MyProject!FSlateApplication::SynthesizeMouseMove() + 265 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:2921]
 MyProject!FSlateApplication::Tick() + 1937 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\slate\private\framework\application\slateapplication.cpp:1219]
 MyProject!FSlateLoadingSynchronizationMechanism::SlateThreadRunMainLoop() + 300 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\movieplayer\private\movieplayerthreading.cpp:132]
 MyProject!FSlateLoadingThreadTask::Run() + 64 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\movieplayer\private\movieplayerthreading.cpp:163]
 MyProject!FRunnableThreadWin::Run() + 86 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\core\private\windows\windowsrunnablethread.cpp:73]
 MyProject!FRunnableThreadWin::GuardedRun() + 93 bytes [d:\buildfarm\buildmachine_++depot+ue4-releases+4.6\engine\source\runtime\core\private\windows\windowsrunnablethread.cpp:26]
 kernel32 + 5805 bytes
 ntdll + 345097 bytes

The test screen that comes with UE4 works fine. Also I had the same error as above except with onMouseEnter. I fixed that by implementing onMouseEnter in my UMG widget. Unfortunately this did not work for onMouseMove.
Btw. I am using the launcher preview.


Hi ,

I just wanted to check and see if you are still experiencing this issue in the released version 4.6. If you are, could you provide a little more detail about how you are setting this up so I can try to replicate it?

Yes I still have this issue. This is my loading screen widget:

This is how I call the code above:

Sorry for the delay. I am guessing that the Show Loading Screen node you have above contains the code you have shown. Is that the only code that node runs? Would you be able to show how you declared the function in your header file?

Yes that node is the code above and it is the only one run. Once I get home I will post the definition.

Ok this is how I declared that function:

UFUNCTION(BlueprintCallable, Category = LoadingScreen)
static void ShowLoadingScreen(UUserWidget* LoadingScreenWidget);

Sorry for not getting back to you sooner. I have been having trouble getting the loading screen to work at all, let alone crash. Let me show you what I have for my set up, and hopefully you can point out what I am missing that will let me figure out what is causing the issue you are experiencing.

My loading screen widget:

My Level Blueprint:

The code I am using is what you provided above, placed into a public UFUNCTION that I added to my character class. The only additional change I made to the code class was including the MoviePlayer class. What class are you placing your UFUNCTION in?

A Blueprint function library. At the moment I do not see why it would not work. (Maybe because it is in the character?) Are you running it in standalone or launch?

I created a new BlueprintFunctionLibrary class and moved the ShowLoadingScreen function into that class, and I am seeing the same results I was seeing before… The level changes but no widget appears while the new level is loading.

class TESTLOADINGSCREEN_API UMyBlueprintFunctionLibrary : public UBlueprintFunctionLibrary
	UFUNCTION(BlueprintCallable, Category = LoadingScreen)
	static void ShowLoadingScreen(UUserWidget* LoadingScreenWidget);

Did you do anything special when creating your BlueprintFunctionLibrary class?

No, are you running it in standalone or launch. Because it only works there.

Sorry, I completely missed that question. I just tried again in Standalone, and I saw a crash happen when changing the level (I still did not see the widget appear, though). I think the crash that I saw is actually slightly different from the one you were seeing, but I think I am getting closer. I’ll jump back into this issue first thing Monday.

You probably have the on mouse enter crash. For this go away you have to add the on mouse enter event in your umg widget blueprint event graph.

I have been able to confirm that there are actually two nearly identical crashes happening in this instance. When I tried to reproduce them in our latest internal build, I was not able to see any crashes, but I am also not convinced the loading screen is working correctly there either (I was using the same code, UMG widget, and Blueprint as I was using in 4.6 and no loading screen appeared when changing levels).

I will check with some developers to see if some functionality has changed, but unfortunately that will need to wait until they get back from the holiday break in a couple weeks.

I have the same problem.
I was able to isolate the issue though, the problem is that the UMG widget is trying to execute some blueprint graph during loading of the level something that is OK till the point where the main thread starts to post load objects.
The reason for why it’s not an issue with the default loading widget is that there isn’t a blueprint attached to it.

Hi DJ_Lectr0 and ,

I apologize for the delay in getting back to you on this issue. There was some discussion on this topic among some of the developers and it comes down to this behavior not being currently supported by the Engine. This is primarily due to the fact that trying to accomplish this goal can result in some potentially very unsafe behavior within the Engine. The GIsRoutingPostLoad assertion mentioned in the callstack of the original post is intended to provide some protection in this area.

There is some support for finding a safe way to provide this capability in the Engine, but it is not likely to be available soon.