Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Fix "tray lags" and language selector disappearance on windows #328

Closed
ZLOFENIX opened this Issue · 13 comments

5 participants

@ZLOFENIX

SFML-master\src\SFML\Window\Win32\WindowImplWin32.cpp
Line 207: while (PeekMessage(&message, m_handle, 0, 0, PM_REMOVE))
Replace with: while (PeekMessage(&message, NULL, 0, 0, PM_REMOVE))
This will remove "tray lags" and language selector disappearance on windows.
Just spent all day to discover it.
YAY !

@LaurentGomila

I think it was already discussed before (did you check the forum?). The thing is, I don't know why it fixes these problems, and I don't know if it has side-effects. I'm not supposed to call this function with a NULL handle.

@ZLOFENIX

I didn't find it on forum.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943(v=vs.85).aspx
Therefore if hWnd is NULL, both window messages and thread messages are processed.

Why there must be side-effects ?
You know how to fix, but you wont - why ?

@LaurentGomila

Therefore if hWnd is NULL, both window messages and thread messages are processed.

If I process messages from other windows, and remove them from the message queue, there will obviously be a problem ;)

Why there must be side-effects ?

See above.

You know how to fix, but you wont - why ?

I didn't say that I wouldn't fix it, but this is not a clean solution. Before applying a patch I need to understand why it solves the problem (and nobody knows, right?) and what bad side-effects it can have (see above).

@ZLOFENIX

You do it wrong.
If not null - messages will be from window.
If null - messages will be from window and from thread.
IMHO not null will not process thread messages and this cause bugs.
IMHO2 you will not get messages from other windows in system, only from your window(s).

@LaurentGomila

IMHO not null will not process thread messages and this cause bugs.

This is possible, so this should be investigated further.

IMHO2 you will not get messages from other windows in system, only from your window(s).

The MSDN says that:
If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread

So, if the program creates both a SFML window and a Qt (for example) window in its main thread, this call will process and remove messages for both windows. This is clearly a problem.

@ZLOFENIX

Ok, i have workaround: add define/var for which PeekMessage use and add it to documentation, so who use sfml to create window will just define var and have no problems.

@LaurentGomila

This is ugly.

I'm sure there is a clean solution; and finding this solution probably requires to investigate the problem deeper (ie. what are "thread events", why does passing NULL to PeekMessage have an effect on this particular bug, etc).

Just because it works for you doesn't mean that this is the ultimate solution and that I should rush to change the code. You've found a solution, great, now you should try to understand it ;)

@retep998

When a window does not have its events handled, it becomes unresponsive. Likewise, I assume there must be some sort of window being created for the taskbar or whatever which has events which are not being handled. By passing a NULL, you receive all events on that thread, including taskbar events, thus eliminating the unresponsiveness. Unfortunately, this also obtains events for other windows, such as a Qt window. Thus, what we need to do is determine the hwnd of the task bar thingy and specifically handle its events as well.

@LaurentGomila

Do you really think that the Microsoft engineers designed the Windows API this way? I don't think so. And I've never seen this in any Win32 program.

Yesterday I've investigated a bit, and found that in other popular graphics libraries/engines, PeekMessage is called with a NULL argument. So if we don't find more relevant information, we could assume that it's safe. However I've also found someone complaining about the same problem on the Ogre forum, and he got no answer. So it may not be totally safe.

@vonj

Actually, based on what I read here, http://msdn.microsoft.com/en-us/library/windows/desktop/ms644943%28v=vs.85%29.aspx , I see no other way of doing it.

"If hWnd is NULL, PeekMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL (see the MSG structure). Therefore if hWnd is NULL, both window messages and thread messages are processed."

@LaurentGomila

And?

No other way of doing what?

@LaurentGomila

Actually, it could be a good idea to check which extra messages are processed when you pass a null HWND, maybe it will help to understand what's going on.

@Oberon00

Maybe you could also try passing -1 as hWnd:

If hWnd is -1, PeekMessage retrieves only messages on the current thread's message queue whose hwnd value is NULL, that is, thread messages as posted by PostMessage (when the hWnd parameter is NULL) or PostThreadMessage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.