Windows gains focus only at borded

[Beta_Ravener]

I've noticed that my windows only gain focus (understand producing sf::Event::GainedFocus and bringing input to that window) only when clicking at it's border, not inside o the window. It's a little annoying and I'm somewhat sure it didn't happen in previous SFML versions (but it's too late for another testing.. ). Other means of gaining focus work fine (alt-tabing, picking up from taskbar,..).

I'm using SFML 2.1 32bit on Windows 8 64bit and can bring up more details if needed, like minimum code to reproduce, however it happens with 2 of my programs using SFML, so it looks like consistent issue.

[eXpl0it3r]

Yeah noticed that as well and was kinda surprised that nobody had reported it yet, but was too busy/lazy to report it myself...

[Ixrec]

Actually it's been known for a while: https://github.com/SFML/SFML/issues/437

[xzbobzx]

Came here to report this actually, it's bugging.

Is there a workaround?
Edit: I fixed it.

[FRex]

You misspelled brought as brough. Otherwise perfect fix.

[eXpl0it3r]

Edit: I fixed it.

Do you mind sharing what you've done to "fix it"?

[G.]

Not really a fix, he displays "click border to focus" with a lame rant in the lower right corner.

[xzbobzx]

Edit: I fixed it.

Do you mind sharing what you've done to "fix it"?

Ah, yes of course.

Basically I've got my event checker looking for the LostFocus event, which switches the 'IsFocused' bool to false. It also switched the gamestate to the pause menu and disables the pause menu's events.
Then later on in the code when I render everything I have my code see if 'IsFocused' is false; if it's false it will display 'Click window border to focus'.
When you regain focus the overlay is removed and it puts the pause menu back in order, from here you're free to continue whatever you were doing.

Not really a fix, he displays "click border to focus" with a lame rant in the lower right corner.

All in good fun 

[FRex]

Not really a fix, he displays "click border to focus" with a lame rant in the lower right corner.

Yeah, he should instead move to some 'lame' library that actually has fully working input handling instead of saying the 'lame' truth that a bug was introduced in one of basic pieces of SFML.

[xzbobzx]

Not really a fix, he displays "click border to focus" with a lame rant in the lower right corner.

Yeah, he should instead move to some 'lame' library that actually has fully working input handling instead of saying the 'lame' truth that a bug was introduced in one of basic pieces of SFML.

Hey now I love this library as much as the next guy, don't judge me for my bad jokes

[xzbobzx]

I fixed my fix :>

[Beta_Ravener]

Hey, when did reporting SFML bugs become such fun to do?  Anyway nice work xzbobzx, in meantime it's going to be probably my choice of 'fix' too. (Might even create fork including this.. or just really fix it.)

[All8Up]

Just posted a reply to the bug tracker with a very simple way to fix this.  It's not 100% thanks to the message order, i.e. you get a click or drop a click prior to the focus message showing up but for my stuff dropping the click was appropriate and all the other messages show up correctly.

[Mario]

IMO clicking into a window to gain focus shouldn't trigger a mouse click event anyway, so seems fine to me.

[All8Up]

Using a tracking flag seems fine, though the one suggestion I would have is to wrap the check in a helper function such that if more logic needs to be added you don't have to fiddle with each message separately.  Just a trivial sort of rule of thumb type thing.

As to the behavior, I actually ended up putting in a flag on the window to control the behavior in my slightly modified SFML 2.1 because in one place dropping the click was completely appropriate but in another it was extremely annoying.  I'm working on a little secondary helper (debug) tools window for editing some items and not being able to click a button immediately without double clicking in that window was annoying.  Clicking on the viewport windows to activate them before mouse clicks were accepted was perfectly fine though.

I still think it would be possible to simply delay the send of the activation click and post it immediately after WM_SETFOCUS is processed, I just wanted the lightest change possible and figured I'd post it for further discussion.