SDK 1.3 Messes with the Foreground Window

So far, Oculus made terrible decisions, instead of setting high standard TRC for shipped application behaviors in the store, they thank they can just hack around everything by themselves.

This is the result, every application not following a basic pattern of being an exclusive VR experience break the assumptions. If they try to pursue in that direction, they will have to patch over patch for every new brokken report case and it will become a nightmare.

They instead need to put control back at least for who want it,like microsoft did with dxgifactory and setwindowassociation.

Update:  For a solution I moved my UI to a separate process and do inter process communication through shared memory.  Since I now no longer create any Windows in the VR process, the UI now works fine.  This was the only way I could figure out how to get around the Oculus Runtime messing with my Windows.  Now Oculus can do whatever it wants with my VR part.

Some of our tools allow editing of content by one user on the desktop while another user is in VR on the same machine.  This kind of non-standard windows behaviour isn't acceptable, and should be changed and instead steered by guidelines/requirements/tests for store submissions.

I have started to look into patching around Oculus home at the moment due to this kind of thing and also the large amount of memory it wastes.

Hopefully Oculus officially addresses and fixes this though in the near future.

Just a thought...
You could try initializing oculus before the window is created. This way it will not find a window to hook into.

Unfortunately they keep calling to change window focus at various points after the window is created it seems. 

To get around the annoyances of the Oculus software and particularly the insanity that is a ~700MB of _Unity_ Oculus home app that runs when your own program tries to use the oculus device, something like the following needs to be done:

1) A slim replacement needs to take over from the fat Unity Oculus home program in "C:\Program Files (x86)\Oculus\Support\oculus-home/OculusVR.exe".  That needs to do the bare minimum of servicing of calls through the API's exposed in the DLL's in "C:\Program Files (x86)\Oculus\Support\oculus-home\OculusVR_Data\Plugins" such as I guess from dependency walker "HomeNativeLib.dll", "OafIpc.dll".

2) A stub DLL for the focus grabbing win32 functions needs to be loaded into your own program so when Oculus calls them through your own program you can neuter them.

3) For reducing the amount of health and safety warning dialog fun if that can't be done via (1) then probably creating a stub xinput DLL in "C:\Program Files (x86)\Oculus\Support\oculus-client" to simulate pressing the gamepad button might be easiest.


Of course it would be nice if Oculus just made their software play nicely with the system - but no official response at all so far on this matter.  I hope they do the right thing so we don't have to resort to such hacks.

Hi @Will_in_Texas, check out the new ovrInit_MixedRendering flag which you can pass to ovr_Initialize(). It should limit focus management to times when your app has created a session (between calls to ovr_Create() and ovr_Destroy()), allowing you to switch between 2D and VR modes more cleanly.