I am reparenting the UE window to a different window using the Win32 API:
[DllImport("user32.dll", EntryPoint = "SetWindowLongA", SetLastError = true)]
public static extern int SetWindowLongA([System.Runtime.InteropServices.InAttribute()] System.IntPtr hWnd, int nIndex, int dwNewLong);
[DllImport("user32.dll", SetLastError = true)]
private static extern long SetParent(IntPtr hWndChild, IntPtr hWndNewParent);
SetWindowLongA(_UnrealEngineApplicationWindowHandle, GWL_STYLE, WS_VISIBLE);
When I do this, the mouse position interpreted by unreal engine is from the top left corner of the monitor, as opposed to the top left corner of the UE window. I have verified this by printing out the GetMousePosition result of the default player controller. When I comment out the SetParent function, the cursor location is correct. When I uncomment SetParent, and mouse to the top left pixel of the UE window, it reports the location of the top left corner of the UE window.
Is there any chance of this bug getting fixed? This is a big issue for my project at the moment…
There are a few questions to help me understand what is happening in your case. When you say the UE window are you referring to the Editor window or a game window (such as the standalone window). If this is a game window does this apply to a packaged version of the game or when playing in the editor? Also, what window are you parenting the UE window to? Do you have similar behavior if you try to reparent the window for another program to a different window?
I am launching the Unreal Engine process two different ways, depending on if I am in development or release. In development, I am launching the Unreal Editor using command line arguments to specify the game and level to run. In release, I am packaging it and running the release executible. In this particular example, I am using the UE editor launching method.
So basically in code in a separate Windows application, I am launching Unreal Engine in code, then grabbing its window and sticking it inside a control in my window. The image below shows this working, and the red rectangle is the only area where the mouse is responsive. This view also shows where I am continuously printing the mouse X/Y position from the player controller, and when I took this snapshot the mouse was at the top-left corner of the red rectangle, so it should be printing around (0, 0), however it is printing (186,207) because it apparently thinks that its local window position is the global screen position.
In this “MainWindow”, the window consists of a simple grid with two columns, the column in the right being 4x wider than the column on the left, and I am sticking the UE window inside the column on the right. As you can see everything works, I just get wonky mouse coordinates.
More discoveries as I continue to test with it, and I understand a little bit of what’s going on. I noticed that the region that the mouse is functional is fixed in absolute screen space. The red rectangle in the image below shows the exact region where the mouse functions correctly, which I determined just by experimenting moving the mouse around and clicking on the scene.
This red rectangle is positioned in screen coordinates at the location that the UE window is supposed to be positioned in relative coordinates, inside my program. Whenever my program resizes, I am doing two things: Moving the window position using the MoveWindow windows API function:
And sending an inter-process message to the UE instance to tell it to set its resolution to the container control’s size. All of this works perfectly as far as the view is concerned, when I move the program around or resize it, the UE window resizes and moves to exactly to where it is supposed to be. The mouse just doesn’t work properly…
See below for a video description of my issue:
I have set up an experiment comparing the same exact code, the only difference being in one case I launch my UE4 game as the process, and in the other case I launch MS Paint. MS Paint functions normally, and the UE4 game has the mouse pointer offset problem.
This seems to be a very fringe case scenario and appears to be platform specific. This workflow is not standard practice and we cannot dedicate the time and resources to finding a fix. If you are using the source version of the engine from GitHub you can find the code responsible for the mouse to try working out a solution in your case. Additionally you may want to look at HTML5 deployment as it sounds like your process is similar.
We are currently dead in the water with this project, due to this issue. Is there any possibility for paid support by someone there at Epic who can get me off Top-Dead-Center with this issue? I would be more than willing to pay to have someone who understands the inner workings help get our team past this so we can complete our project, as the delays will be much more expensive for us. Alternatively, are there third parties knowledgeable with the engine viewport code that would be available to support us?
Thanks so much!
Unfortunately we do not offer a form of paid support . You may want to reach out to other community members on the forums (https://forums.unrealengine.com/) who may have experienced something similar and have suggestions for your situation.
After some years now, have you achieved to control the mouse correctly? I’m trying to do this just now.