for looking into this Matthew. Due to the nature of this bug, I know that I can’t expect a resolution soon, and the better bet is for me to just do a reinstall of Windows. I’ve noticed at least one other application behaving the same way (non-Epic), so I’m feeling pretty sure that we are just waiting on Windows for this one.
Hello GitNick,
That’s some interesting news. I still plan to bug it if I can get it to occur, but what other software was it that you experienced this issue in if you don’t mind sharing? If he is able to share it, could you give it a try as well, if you haven’t already switched back, to see if you see the problem?
I have experienced this bug with no other software. While it’s clear that something changed with Windows in the insider preview, the fact that it’s only happening in UE (for me) makes me inclined to say that it should be considered a problem with the way UE does it’s menus
I’ve tried various other software, such as Adobe programs, FL Studio, Blender, even one’s that use a more “custom” menu, rather than the tradition win32 style.
The bug is still present in Windows 14926.
Something really interesting, though, is that the update that happened to the Epic Launcher today brought back functionality to the settings and friends menu, which previously did not work. It also seems that the UE menus are more likely to work, albeit after some serious hang time. It may also be worth mentioning that certain menus do work, such as the dropdown on the “Launch” icon and the category filter in the UE marketplace in the launcher, and all the drop downs in the details and settings, and similar, panels.
I think I forgot to mention before, but the CPU usage ramps up like crazy when the menus are being used.
This BUG is confirmed and in W10.14926.1000 Pro Insider Preview 1607.
All File Menu is broken + DropDown Menu not work in any window (Toolbar, Viewport, anywhere where is placed drop-down arrow)
P.S.: Definitely Microsoft changed some part of UI (which is very probably to present in the next final release) and now the ball is in Epic’s court
Check avi file in attachement
link text
This BUG is confirmed and in W10.14931.1000 Pro Insider Preview 1607. All File Menu is broken + DropDown Menu not work in any window (Toolbar, Viewport, anywhere where is placed drop-down arrow)
To me this behavior looks like some sort of render state isn’t cleared properly anymore in Win10 14915+ hmm, curious
This bug in my windows10 14931 still exists.
I nailed down the cause of the problem to the “WS_EX_COMPOSITED” extended windows style used by the pop-up child windows. Removing it causes the popup menus to work properly.
The problem can be “fixed” with a small change to the source code. Open Engine\Source\Runtime\Core\Private\Windows\WindowsWindow.cpp then locate and comment the following line:
WindowExStyle |= WS_EX_COMPOSITED;
…then compile the editor.
From a quick glance I haven’t seen any abnormal side effects.
Also, remember to report/upvote this on the Windows Feedback Hub, because it does sound like a bug on their side (I’ve been reading about WS_EX_COMPOSITED and it doesn’t have a very pretty history, compatibility-wise).
I haven’t done extensive tests to determine if this is a bug with all windows that use WS_EX_COMPOSITED or if it’s something related to a particular combination of flags with WS_EX_COMPOSITED.
EDIT:
The more I read about WS_EX_COMPOSITED, the more I think it shouldn’t be used the way it’s being used. It seems to have a purpose only with DWM disabled (to prevent flickering by using double buffered painting on windows), but currently UE4 enables it only if DWM is enabled (which in Windows 8.1 and 10 means "always).
manoelneto, you are the men!!! Right in the center- the BUG is down. Congratulations for your clear work.
Tested and confirmed on W10.14931.1000 Pro Insider Preview 1607 and in UE4.12.5+UWP and in UE4.13.
Perfect work
The binary version of engine can’t compile the source code, so i get the GitHub version then comment this line, another step is switch engine version in my project.
It’s done!
for your help.
Thank you for the research manoelneto. Would you like to make a pull request for this change on our Github repository? If so, this would allow the change to be reviewed by one of our developers that cover that field and determine if it is an acceptable change or would cause issues elsewhere, as users not on this version or with other setups may see other problems by removing this line.
Otherwise, I’ll put in the report myself once I get a reproduction, mainly so I can confirm that it happens now and that the fix given fixes the issue.
Edit: Currently, there’s an issue with Github where new pull requests are not able to be entered along with existing ones not being able to be edited other than adding comments. If you wish to make a pull request, let me know and I’ll post here when this is fixed.
I also have this problem with 4.12 and 4.13 on w10 Dev Preview 14936.rs_prerelease.160923-1700
I have to run the editor in openGL mode in order to get any menus…
I have the same issue in the launcher now, can not get any menus…
I am currently an insider and had another update last night to Build 14936.rs_prerelease.160923-1700. I have also updated to editor version 4.13.1. I am still having this issue, though there appears to be a one line fix (per the answer below by manoelneto).
I did try running the editor per this last comment in openGL (I hadn’t thought of that - DarkLichNY!) and the menus are completely responsive now, though the project I tested this on had to recompute shaders (takes a while) and it took a while to load. So this is a good workaround if you want to keep your Win 10 insider build and remain productive.
There isn’t an option in the Epic launcher to start in openGL (that I could find), so it turns out you have to create a shortcut first:
Then on the new shortcut on your desktop, right click and select properties. Add the -opengl to the target AFTER the quote:
I am hoping this gets fixed before this insider preview build becomes public to everyone. Those who aren’t following this thread will certainly become upset if not. My understanding is that this is a one line fix - it shouldn’t be too difficult to push it to the source, test it ASAP and be put on the next release. Otherwise, perhaps the Epic launcher should launch the openGL version of the editor (this should make all versions work, I would think) by default with a caveat to the load time the first time this is done.
1 Like
Confirmed this will fix this issue. Running Win 10 Pro 14936.rs_prerelease.160923-1700 and UT 4.12.0-3101884+++depot+UE4-UT-Releases
I’m glad to hear that you all have a fix for the moment. I managed to get a hold of a drive with Windows 10 Pro and have signed it up for the Insider Preview builds, now all I have to do is wait until the build is delivered and then I’ll be able to reproduce this (hopefully) and get a report in. As far as those Github issues I mentioned previously, they’ve been fixed so if you would like to enter a pull request for this change Manoelneto, you can feel free to do so.
I was able to get updated to the following prerelease build:
Build 14936.rs_prerelease.160923-1700
I was able to reproduce the issue and have entered a bug report as a result. You can find the bug report here: UE-36752. This should let us start looking into fixing this. I included manoelneto’s fix in the description so that can be taken into account but it may not be the same as the resulting fix.
So, this bug report has, at this writing, been logged as ‘cannot reproduce’ and given a RESOLVED date… can you follow up, Matthew? Maybe they didn’t read that it involves Windows Insider builds.
Maybe in the meantime everyone can up vote the bug so it’ll get more notice?
Hello RobMilliken
I’ve left a comment for the person who marked it as Cannot Reproduce to ensure that they were using the correct environment when testing. Upvoting an issue is always a good thing, it’ll show more community interest in the bug.
Im on the latest Insider Preview 14942 and i started the Editor with the -D3D12 parameter. All menus work just fine 
The person reviewing it didn’t notice that it was preview, as we had guessed. A fix has been entered for the issue on one of our internal streams. It’s different from manoelneto’s fix and should be visible on Github whenever the fix is merged into our Main branch.