Windows 10 - SDL_PRESSED behaves like SDL_RELEASED

Hello,

SDL2-2.0.22 64bit on Windows 10:

Within the event SDL_MOUSBUTTONDOWN the value SDL_PRESSED behaves like SDL_RELEASED.

Is that a known bug?

Kind regards,

Nik

That is the code snippet:

if(myapp->event.button.button==SDL_BUTTON_LEFT && myapp->event.button.state==SDL_RELEASED)

With SDL2 2.0.9 everything works fine.

Any comments?

So you’re getting a SDL_MOUSEBUTTONDOWN event, where event.button.state is SDL_PRESSED or is it SDL_RELEASED?
Or what?

I think you should post more code - that shows where myapp->event comes from, how you use it etc. Just that line is not enough context

Sorry, my failure. That was the sister line of code. Now the right lien:

if(myapp->event.button.button==SDL_BUTTON_LEFT && myapp->event.button.state==SDL_PRESSED)

There is a SDL event loop. If and as long as the left mouse button is pressed a scroll action should happen (connected action).

With SDL2-2.0.22 the connected action stops although the left button is still pressed and not released. Hence, SDL_PRESSED behaves like SDL_RELEASED. On Linux and also on Windows with SDL2 2.09 the SDL_PRESSED event holds on as long as the button is pressed.

Can you post a simple example? Or submit a standalone example in a bug report at Issues · libsdl-org/SDL (github.com)?

Do you first make sure that myapp->event is actually a SDL_MOUSEBUTTONDOWN (or -UP) event?
Or is it just the latest event you polled, which could be of a totally different type (which means that accessing it as a mouse button event will return nonsense values)?

(Meaning: is myapp->event.type SDL_MOUSEBUTTONDOWN or SDL_MOUSEBUTTONUP or something else?)

Here is the code example:

SDL_Event event is part of the structure myapp.

void menu(struct geeonx_appdata *myapp)
{
int go_out;
go_out=0;

while(go_out==0)
{

    SDL_PollEvent(&(myapp->event));
    
	
    switch (myapp->event.type)
    {
			
		case SDL_MOUSEBUTTONDOWN:
     
		if(myapp->event.button.button==SDL_BUTTON_LEFT && myapp->event.button.state==SDL_PRESSED) 
		{ 
            /* Do something */
        }
        break;
     }
}

I have tested SDL releases 2.0.11 and 2.0.12 on Windows 10 which also work fine. On Linux Mint I use the the SDL release 2.0.10 provided in the repository. Hence, it may also be a Linux issue.

event is a SDL_Event union.

Made a bug report with standalone example on
github.

You need to check the return value of SDL_PollEvent. If there was an event it will return 1, otherwise it will return 0 and in that case I don’t think you’re supposed to actually use the event object (not sure if it’s guaranteed to leave it unmodified or what, the wiki doesn’t say).

It sounds like you expect SDL_PRESSED to get fired multiple times, for as long as the button is hold down, but I don’t think that is the intended behaviour. If that is the behaviour you have experienced in the past then it was probably just a coincidence due to incorrect usage of SDL_PollEvent.

Yeah, as @Peter87 says, you should check the return value of SDL_PollEvent(). And since there may be more than one event pending, you should call it from its own while loop, like this:

while(go_out == 0) {
    // check all pending events
    while(SDL_PollEvent(&(myapp->event))) {
        switch(myapp->event.type) {
        case SDL_WHATEVER:
            blah blah
        }
    }
}
1 Like

Thanks for your comments also @Peter87 but that does not solve my problem. I want to receive a firing “pressed”=event.button.state==SDL_PRESSED as long as the mousebutton is pressed.

At least until SDL2 2.0.12 that was the normal behaviour. Please take a look at my video at github. showing little click_demo WIN64 program in action.

Press the left mouse button (without releasing it) and then do some action that triggers a different event (e.g. move the mouse slightly or press a key on your keyboard) and you’ll see that you no longer get the SDL_PRESSED event so it didn’t really work in the old versions either.

I suggest you come up with a different way to do what you want to do that doesn’t rely on getting multiple SDL_PRESSED events for the same click because that is not how SDL works.

1 Like

Thanks for the hint. I have done a buffer solution and I am not using SDL_PRESSED anymore. Instead I store the SDL_MOUSEBUTTONDOWN signal as long as it is deactivated by SDL_MOUSEBUTTONUP.