first mouse click in window after window creation not registered

I use case SDL_MOUSEBUTTONDOWN.

Keyboard Events are registered.

When I have a console allocated and I printf inside SDL_MOUSEBUTTONDOWN the first click is registered.

When I use SDL_ShowSimpleMessageBox (passing the window) inside SDL_MOUSEBUTTONDOWN the first click is neither registered (so this debugging confirms it isn’t). Neither is first case SDL_MOUSEBUTTONUP registered.

Neither when mouse already is over window on window creation or when hovered over window afterwards.

Window created with SDL_CreateWindow("name", SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED, WIDTH, HEIGHT, SDL_WINDOW_RESIZABLE);.

Neither does | SDL_WINDOW_MOUSE_FOCUS avail.

Neither does SDL_RaiseWindow(window) avail.

Neither does

  SDL_SysWMinfo info;
  SDL_VERSION(&info.version);
  if (SDL_GetWindowWMInfo(window, &info)) {
      EnableWindow(info.info.win.window, true);
  }

(header included) avail.

But this avails:

int x, y;
SDL_GetWindowPosition(window, &x, &y);
SDL_WarpMouseGlobal(x + centerX, y + centerY);
INPUT fakeFirstClick[2];
fakeFirstClick[0].type = INPUT_MOUSE;
fakeFirstClick[0].mi.dx = 0;
fakeFirstClick[0].mi.dy = 0;
fakeFirstClick[0].mi.mouseData = 0;
fakeFirstClick[0].mi.dwFlags = MOUSEEVENTF_LEFTDOWN;
fakeFirstClick[0].mi.time = 0;
fakeFirstClick[0].mi.dwExtraInfo = (ULONG_PTR)NULL;
fakeFirstClick[1].type = INPUT_MOUSE;
fakeFirstClick[1].mi.dx = 0;
fakeFirstClick[1].mi.dy = 0;
fakeFirstClick[1].mi.mouseData = 0;
fakeFirstClick[1].mi.dwFlags = MOUSEEVENTF_LEFTUP;
fakeFirstClick[1].mi.time = 0;
fakeFirstClick[1].mi.dwExtraInfo = (ULONG_PTR)NULL;
SendInput(2, fakeFirstClick, sizeof(INPUT));

I think SDL_WarpMouseInWindow(...) didn’t warp the mouse pointer after window creation (I don’t remember exactly).

Visual Studio 2022, Intel C++ Compiler, Windows 11

SDL 2.28.4

The problem is that SDL is registering the first click as a window grab-focus event instead of a regular mouse click. This does feel like a bit of a bug that it doesn’t auto-grab focus when the message box is shown. It might be something to bring up at their github issues page if a developer doesn’t notice it here.

I might have a work-around for you for today:
There’s a hint that you need to pass SDL that says to capture the first mouse click on window focus;

Somewhere after the SDL_Init() function, before your main loop, you tell SDL to follow this hint;
SDL_SetHint("SDL_HINT_MOUSE_FOCUS_CLICKTHROUGH", "1");
SDL2/SDL_SetHint - SDL Wiki
I don’t use the message box, so I’m not 100% certain that setting that hint will apply, do you mind confirming if it works?

If it does work, then you might try setting the hint before calling the message box, then un-setting it after the box closes if you wish to maintain the main window’s grab-focus behavior.

1 Like

Hi, this did not work, neither after window creation before my main loop nor after init before window creation.

The message box was only for debugging, the main window itself does not receive an event for the first click.

I thank you very much nevertheless !

EDIT: first mouse click in window after window creation not registered · Issue #8358 · libsdl-org/SDL · GitHub

Are you able to share more of your code, or a stripped down version at least to give us a broader view of how you’re using SDL?

yes, https://github.com/u-an-i/Globe/blob/5bd1b87fc837a6fd1769e559d1b491809ce91c5e/Globe.c#L1583

I don’t have a Windows machine to test your code on, I apologize for the guess.
What if you set the mouse position to more than zero for your fake mouse clicks?

Would it be enough to catch this event,

SDL_WINDOWEVENT_FOCUS_GAINED

Then use

SDL_GetMouseState(int *x, int *y);

The fake mouse click works. They make the window taking mouse clicks in the first place. Otherwise the user has to click into the window once himself without anything happening and then the second++ mouse clicks produce events.
I like the first mouse click of a user into the window to produce an event. Using the fake one beforehand this works.

You should include minimal reproducible example that anyone can compile and run to help you with your problem. Guessing and questions are time-consuming :grin:.

i already have a solution. :slightly_smiling_face:

this was meant to be a sort of bug report. :roll_eyes:

And i thought i have been extensive, detailed and clear in describing problem, context, non-working attempts and solution. “First click in created window makes no event” what is there to guess ? :face_with_open_eyes_and_hand_over_mouth:

I appreciate you attempting to help !

This works for me, and the very first mouse click after window creation is captured. But I don’t see that code anywhere in the OP’s listing, even though he claims to be using it.

I tried it based on GuildedDoughnut s suggestion. But it did not help.

It’s a “default” main loop polling events in SDL. I thought I can allow myself the luxury of brevity.

I still think you should include it in your code, because it should help and without it your ‘bug’ report is invalid.

The only other major difference between your code and mine is that I’m using an OpenGL window, even in Windows.

I see, I understand. I add it to the bug report that that did not help.

Edit 2: I added it to first mouse click in window after window creation not registered · Issue #8358 · libsdl-org/SDL · GitHub

I wasn’t made aware of this through reading the Wiki documentation about creating windows, actually I didn’t find the “create window” call listed in the Wiki at all, SDL2/CategoryVideo - SDL Wiki , I stumbled upon it through SDL2/SDL_WindowFlags - SDL Wiki .

Edit: the first link is linked from SDL2/APIByCategory - SDL Wiki
image

Btw.:

Would an OpenGL window provide a performance benefit compared to a “default window” and SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_PRESENTVSYNC); ?

Would I have to make considerations in my code if I create an OpenGL window ?

@Uani I’m pretty certain that using the OpenGL flag tells the library that it should set up to accept/load the OpenGL functions, and it might maintain an OpenGL context (I’m not too sure how that works exactly). After using the OPNENGL flaf, the window itself is just a normal window that is ready to work with OpenGL calls. It would be very interesting to me if setting that flag fixes the issue. If it does help, then adding that to the bug report should help the developers to track down the issue.

@rtrussell what version of Windows are you using? Uani said they’re on Windows 11, I’m curious if there might have been some change to the WinAPI between your OS versions.

The SDL_SetHint() function that I mentioned worked on Ubuntu Wayland, but not Ubuntu Xorg. Setting the OPENGL flag in XORG did not make a change on my system.

Windows 11. I created a new window and the first mouse-click gets reported in a SDL_MOUSEBUTTONDOWN event, unless I’m somehow confusing myself.

In Windows a default ‘accelerated’ window will be using the Direct3D backend; whether OpenGL would give you better or worse performance I don’t know, but I wouldn’t expect there to be much difference (both use the same GPU, after all).

I use OpenGL on all platforms because I make direct calls to it (this is supported by SDL2, it’s the main reason for the SDL_RenderFlush() API).

1 Like

i only reported what i found with “Visual Studio 2022, Intel C++ Compiler, Windows 11, SDL 2.28.4” and my app in which i think i do only “default” SDL calls. It was reproducible every time for me like outlined in my original post.

@rtrussel - The problem as I understand it is that when you click off the window (lose focus), then click back on the window (gain focus) that first click on gain focus does not also send a mouse_down or a mouse_up event.

It seems that Uani would especially like to have the messageBox capture that first mouse click. (This should be the default behavior for the message box: I can understand the frustration behind clicking the popup window directly on a button and not have anything happen.)
[Edit: Uani clears up below that this is not actually the issue? I’ve lost track of what the actual problem is at this point.]