Jump to content
Eternal Lands Official Forums
LabRat

Possible fix for mouse click away bug

Recommended Posts

There is a bug that manifests sometimes wherein if you click away from the EL window, the client receives the mousepress and acts on it.

 

Hopefully the below patch may stop it, it seems to work for me:

 

http://developer.berlios.de/patch/index.ph...p;group_id=1256

 

Let me know if it works for you or others please :)

Share this post


Link to post
Share on other sites

a modified version of this (check in events.c instead of elwindows.c) is now in CVS, thanks :)

Share this post


Link to post
Share on other sites

Great, that had bugged me for ages, but I didn't know the command, I was trying to see if SDL_lostfocus was anything to do with it but I couldn't find an example out there in cyberspace :)

Share this post


Link to post
Share on other sites

I'm glad that it helped you, but code that is in cvs now is rather confusing:

if(event->button.x >= window_width || event->button.y >= window_height || (SDL_GetAppState() & !SDL_APPMOUSEFOCUS))

 

1. Why we test only for >=, but do not test for < 0? (Edit: because it is Uint i think :happy: no problem here then)

2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this:

!(SDL_GetAppState() & SDL_APPMOUSEFOCUS)

Edited by Alia

Share this post


Link to post
Share on other sites
1. Why we test only for >=, but do not test for < 0? (Edit: because it is Uint i think :) no problem here then)
not just that it's Uint (which means, if it were negative, it'd be a really large positive number instead) but also because it's (AFAIK) a position in our window, not the entire computer screen (unless they're the same, i.e. fullscreen)
2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this:

!(SDL_GetAppState() & SDL_APPMOUSEFOCUS)

darn it, yes, good spotting (I guess it's theoretically possible to &-match an inverted value, but that'd be the case of "this is off, everything else on")

I'll fix that in CVS now

 

ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all

Edited by ttlanhil

Share this post


Link to post
Share on other sites

ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all

 

If you think it is only windows-sdl bug, maybe we should #ifdef those checks for windows only and look if linux people will

report about unfocused keypresses and mouse clicks?

 

Not for release of course, but in cvs.

Share this post


Link to post
Share on other sites

IMO, the simpler the code, the better. it's not going to have an impact on performance, and we don't know for sure that it's windows only (my best guess is that it's a window manager issue. there may be some other funky window manager out there for *nix that does similar)

Share this post


Link to post
Share on other sites
2. SDL_GetAppState() & !SDL_APPMOUSEFOCUS is always false. I think you were going to type this:

!(SDL_GetAppState() & SDL_APPMOUSEFOCUS)

darn it, yes, good spotting (I guess it's theoretically possible to &-match an inverted value, but that'd be the case of "this is off, everything else on")

No, that'd be

SDL_GetAppState() & ~SDL_APPMOUSEFOCUS

The ! operator does a logical negation, not bitwise, so !(anything non-zero) = 0.

 

ed: removed "will fix" comment in quote for clarity

Edited by Grum

Share this post


Link to post
Share on other sites

well, d'oh, that's what happens when I post about bitwise operations when I haven't read about them for a while (by chance, I did read about them later)

so yeah, using the !, you'll always get (var & 0) (unless the define is for 0, ie NOTHING_WRONG in some cases)

 

oh well, the correct (I hope :) ) code is in CVS anyway

Share this post


Link to post
Share on other sites

ed: I would like to point out one thing, however, the windowing system that sends mouse-click events to programs that don't have focus at the time is (to my mind) messed up. as far as I'm concerned, this is either a windows bug, or a windows-sdl bug; same as the other cases of shared keystrokes and all

Since this change went into CVS I've started occasionally loosing mouse use in the client. I have now worked out how to reproduce the problem. I'm using debian etch with the gnome desktop and the metacity window manager. I have "Select windows when mouse moves over them" enabled in my gnome window preferences but I get the same problem if I turn it off. I run el in a window that occupies most of my screen. Here's how the problem can be reproduced.

 

1) Using the mouse, switch from EL to another applications that overlaps the EL window.

2) Make sure the mouse position is in the other application but also over the EL window underneath.

3) Use ALT-TAB to switch back to the EL client.

 

The window focus goes back to EL (the title bar is highlighted), I can type text. However, no mouse button functions work. If I move the mouse outside the EL window and back in, all is well again. I have added some debug to see what is going on. The code described above is kicking in and ignoring the mouse events as SDL_GetAppState()=6, SDL_APPMOUSEFOCUS is not set. However, the EL window does have focus and has just received an SDL_VIDEOEXPOSE event which it ignores. The released version of the client does not show this problem. Admittedly, this may be a fault of my window manager but I thought it worth letting you know.

 

Edit: Edited as I had not quite managed to reproduced 100% with my first method, now its 100%.

Edit2: Clarified, it's mouse button function that don't work.

Edited by bluap

Share this post


Link to post
Share on other sites

meh... well, right now what we do is ask SDL if we have mouse focus... given the above, it sounds like either SDL or the window manager is giving bad info

Share this post


Link to post
Share on other sites
Since this change went into CVS I've started occasionally loosing mouse use in the client.

I've been fighting with this too. Since I play with EL displayed in a window (non-fullscreen) I frequently have to move the mouse out of the client and back in to get it to actually take focus. So far, the problem only manifests with the EL client.

 

Using bluap's steps I can reproduce this 100% of the time.

 

Running: Debian Etch, with Openbox v3.2 as my window manager.

Share this post


Link to post
Share on other sites
Since this change went into CVS I've started occasionally loosing mouse use in the client.

I've been fighting with this too. Since I play with EL displayed in a window (non-fullscreen) I frequently have to move the mouse out of the client and back in to get it to actually take focus. So far, the problem only manifests with the EL client.

 

Using bluap's steps I can reproduce this 100% of the time.

 

Running: Debian Etch, with Openbox v3.2 as my window manager.

I've been getting this too! I thought it might be just me (drivers etc), but i'm glad i'm not the only one. Whenever I alt-tab out of the client (I run it in windowed mode), moving I have to hover over something outside EL (such as the XFCE taskbar) to gain mouse control in EL (funnily enough, I can still see the animated X when clicking to move, but no movement)...

Share this post


Link to post
Share on other sites

This is, IMO, an SDL bug (and hardly the first issue in SDL we've encountered).

I can't seem to reproduce the problem, so could someone test the following?

Index: events.c
===================================================================
RCS file: /cvsroot/elc/elc/events.c,v
retrieving revision 1.141
diff -u -r1.141 events.c
--- events.c	9 Jul 2007 15:11:05 -0000	   1.141
+++ events.c	26 Jul 2007 05:06:53 -0000
@@ -117,7 +117,7 @@
			case SDL_MOUSEBUTTONDOWN:
			case SDL_MOUSEBUTTONUP:
					// make sure the mouse button is our window, or else we ignore it
-					   if(event->button.x >= window_width || event->button.y >= window_height || !(SDL_GetAppState() & SDL_APPMOUSEFOCUS))
+					   if(event->button.x >= window_width || event->button.y >= window_height || !((SDL_GetAppState() & SDL_APPMOUSEFOCUS)||(SDL_GetAppState() & SDL_APPINPUTFOCUS)))
					{
							break;
					}

With this code, if we have the keyboard focus but not mouse focus (according to SDL) then we still allow it to go through, depending on the coords. This isn't really correct, but hopefully it'll fix this problem without causing others (allowing clicks outside the window to do stuff inside the window is the other side of the problem)

Share this post


Link to post
Share on other sites

I haven't tested this, but looking at it: doesn't this patch ignore all mouse events now when the window has keyboard focus?

Share this post


Link to post
Share on other sites
I haven't tested this, but looking at it: doesn't this patch ignore all mouse events now when the window has keyboard focus?
I think you missed where the parenthesis are; !(mouse or keyboard)

Or was there something else I missed?

Share this post


Link to post
Share on other sites

Nope, you're right, i missed the extra set of parentheses. Sorry for raising a false alarm.

Share this post


Link to post
Share on other sites
This is, IMO, an SDL bug (and hardly the first issue in SDL we've encountered).

I can't seem to reproduce the problem, so could someone test the following?

I've made the listed change to my CVS checkout (updated moments ago) and will keep you posted. However, initial results are very promising.

 

Edit:

So far it appears to be working fine. There still appear to be some focus issues (sometimes the client window doesn't seem to get focus until I click somewhere inside it), but the situation is much improved. I would consider this change a very positive one.

Edited by jamincollins

Share this post


Link to post
Share on other sites

Well, since I haven't had any reports of it causing new problems, it's now in CVS. Hopefully it'll now be as good as we can get it :)

Share this post


Link to post
Share on other sites

Thanks, he bug seems to be fixed my end. Although i'm still having to press CTRL twice when trying to CTRL+CLICK (drop all) from the quickbar. Is this related?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×