I have an OpenGL application that uses GLFW under OSX 10.12.3.
50% of the time when I run it it works fine. When glfwPollEvents() is called from my main loop, the mouse callback is called correctly for mouse events.
However, the other 50% of the time it doesn't receive ordinary mouse events even though a window is correctly created in the foreground. The main loop is running but the mouse event callback isn't called. If I double click (two clicks within around 0.1s) then the event callback receives 4 events as expected. But it receives nothing for single mouse clicks.
Within the main loop glfwGetWindowAttrib(window, GLFW_FOCUSED) returns 1 when the code is working and 0 when it isn't. Adding glfwFocusWindow(window) after window creation doesn't seem to change anything.
If I switch focus to a different application and switch back then my application starts receiving events correctly.
I have used GLFW 3.1.2 built using homebrew, and GLFW 3.2.1 built directly from a github clone. I get the same behaviour either way.
For a while I thought glfwWindowHint(GLFW_FOCUSED, 1) fixed my problems but after the 10th launch or so the problem returned.
I'd like to avoid posting my code (whose glfw calls come mostly from tutorials anyway) and I'm hoping someone will recognise the symptoms I describe as some obvious mistake I've made. The double click behaviour seems like a big clue.
Related
A little background
Our application (AppA) is calling a 3rd party application (AppB). We are simulating AppB's window as being modal to our application.
pseudo
while AppB_Running
If AppA_focused
SetForeGroundWindow(AppB_Hwnd)
HandleMessage
SetForegroundWindow(AppA_HWnd)
This has been working for years without incidents, that is, until we started rolling out Windows 10. We started receiving reports that a random app (AppC) was sometime getting the focus when we closed AppB (Actually, given our user's tech expertise, the report were more along the line "Closing AppB kills AppA" but I digress). That behavior can be reproduced occasionnaly(<5%) on dev machine (But not yet while debugging...)
So far, test result suggest AppC is the application that had the focus before AppA.
Is there a way I can ensure AppA gets the focus back when AppB closes?
Extra notes
The problem can be reproduced even if AppA only ever loses focus to AppB. (AppC never being focused after AppA started)
While this does not directly answer my original question, it does give some more insight on the problem and might be useful to someone else.
Part of the issue was an oversight on our end. More specifically, the way we obtained AppB_HWnd. We basically picked the first top level window we encountered. In our current test case, that window happens to be an invisible windows ('MSCTFIME UI'). Calling SetForegroundWindow on an invisible window doesn't seem to cause problems per se, Windows seems to just bring to front one of the process' visible window. It is when said process does not have any visible windows left that things seems to go awry. That usually happen in our case between the moment AppB's main window is closed and the moment the process ends.
So... Don't call SetForegroundWindow on an invisible window
As for why we didn't have any trouble in Win7? Maybe the first window was always a visible one. Or maybe SetForegroundWindow behaved differently back then.
I’ve encountered a problem I can’t solve.
I’m working on a project with MFC in Visual Studio. The problem is, sometimes GUI just stop visibly reacting, but technically it keeps doing the functions it was intended to do. It means, when I press a button, the function OnBnXXXPressed is executing, but the button doesn’t look like it was pressed, as if I’ve pressed on a picture of button, not the button itself. And it’s not just this button — every other element of GUI seems to keep working, but doesn’t show that it is working.
Also, in this state dialog windows don’t show up upon their call. If I call AfxMessageBox, the message box won’t show up, and the thread that called this function, will not be blocked; AfxMessageBox will basically be skipped.
I have absolutely no idea what can possibly cause that behavior. The question is: what should be happening in program for it to behave this way? Especially if it’s built with MFC?
The project consists of 50+ files, and every function responsible for GUI makes changes to the elements it is about. I do not know where the error is, and I ask you, to the very least, where should I look for it.
Thank you for attention!
The answer was originally provided in the comment section. My code indeed has a GDI resource leak that was provoking this behavior.
When a button is clicked, are you doing a bunch of processing, or do you return fast? If you don't return, maybe locking the UI thread. After a user presses on the button, how long is it taking before the OnClick for that finishes running?
If that's it, here's some more info: https://learn.microsoft.com/en-us/windows/desktop/Win7AppQual/preventing-hangs-in-windows-applications
The solution I've generally used for long-running logic on a UI click is to run it a background thread.
I've just encountered a really bizarre scenario and can't find any info on this elsewhere. When Xcode breaks at my breakpoints, all keyboard entry for the whole system is unresponsive. I can switch to another app but no key strokes are recorded. Xcode itself is unresponsive to keyboard input.
Anybody else seen this?
I'm running 10.10.1 and Xcode 6.1.
Based on the comments above it would seem that this issue has to do with behind the scenes details of Powerbox. To explain further: my app is sandboxed and calls NSOpenPanel. When breaking (Xcode breakpoint) in the completion block of NSOpenPanel I experience system-wide keyboard input loss.
Keyboard entry behaves normally in breakpoints outside of the call to NSOpenPanel. After working past this area of code I observed that my subsequent operations (queued in the background from the completion bock) often finish before the NSOpenPanel is completely torn down (disappears from the screen). My assumption is that until NSOpenPanel is removed from the screen (and maybe further after), Powerbox won't release control of the keyboard.
Much of this is assumption since I don't have the actual Powerbox code and can't step into it but it seems to fit.
I worked around my debugging issues by utilizing print statements and stepping through code with the variable inspector open. Mouse input continues to function so you can right-click (if you have a two-button mouse) on the variable and print its description at least.
Thanks for the help Ken.
UPDATE
I am now delaying execution of any of my post-NSOpenPanel actions using dispatch_after. On my system a delay of 1 second is doing the trick. I really don't like adding arbitrary delays but this seems to work.
I'm currently trying to build and run an UnrealEngine4 demo app, which uses SDL2, on a Linux armv7 embedded system with X server running but no window manager.
What I'm seeing is that the app is not responsive to keyboard events, although mouse works fine.
Digging further it turns out the problem is that UE4 ignores the keyboard event if the SDL_Event.key.windowID does not match the ID of the app's SDL_Window. I verified this by calling SDL_GetKeyboardFocus() and it turns out the window ID for the keyboard focus is 0 whereas the app's window's ID is 5.
Digging a bit further inside SDL2 it looks like the keyboard focus is set to a particular SDL window after a focusIn event is received from the X server. (see X11_DispatchEvent() in SDL_x11events.c).
It looks like if you're running X11 without a window manager however this focusIn event is never generated by the X-server as already answered here:
FocusIn/FocusOut not generated
After hacking X11_RaiseWindow() in SDL_x11windows.c by adding:
X11_XSetInputFocus(display, data->xwindow, RevertToParent, CurrentTime);
SDL_SetKeyboardFocus(data->window);
was able to finally get the keyboard events processed.
Does the above assessment sound correct ? If so is there a clean solution to this ? I'm still digging around but any suggestion would be greatly appreciated.
Thanks
This turned out to be a bug in SDL, which we just pushed a fix for:
https://hg.libsdl.org/SDL/rev/aa4e4768c6c1
This fix will be in SDL 2.0.4, and should bubble over to Unreal shortly thereafter.
So I just built an OpenGL application on a Mac for the first time. I'm using GLUT to get keyboard input. The trouble is, I've discovered that if I'm moving the mouse at the same time I push a button on the keyboard, my keyboard function doesn't get called! If I push a button when the mouse isn't moving, it gets called just fine. The same goes for my keyUp function. Why could this be?
I'm also having trouble with the mouse motionFunc - it seems to not be getting called every frame and lead to choppy mouse input ...
Can you provide a code sample? It sounds like a bug in your event handling code.
That said, GLUT is no longer developed and you should not be using it. There are numerous better alternatives, the most popular being SDL. Others include GLFW and SFML, and you can even use Qt.