Polling events after attaching to existing window

[mary2409]

Hi, I am kind of asking for confirmation about the documentation that says "Events must be polled in the window's thread".

I have an open GL render window, but for various reasons, I'm not binding to it for window events such as mouse and keyboard. I got annoyed at having a separate window that I have to click and type into, so I looked into sfml's ability to attach to existing windows. I got the window handle correctly, I attach to it, but now it only halfway works for polling events. It reads keyboard events fine, and it reads *one* mouse event , MouseMoved, but not all the other mouse events, such as mouseButton press/release, etc. I looked at the documentation and found that discouraging bit about how events must be polled in the thread that created the window. But I wanted to ask here for confirmation because this is kind of a gray area. I "created" an SFML window, just from a handle instead of from scratch. I confirmed that the window I'm binding to does not already poll for any events. It just creates a GL context and calls display on it.

Can anyone shed some light on this, basically just confirm I can't expect things to work this way ? Thanks.

Mary

[eXpl0it3r]

What exactly is the reason that you can't work with an SFML window from the start?

[mary2409]

I forgot to specify: they are both sfml windows. I want a completely separate process , which currently reads in mouse and keyboard events from its own SFML window to instead attach to the SFML of another window, via its window handle. The attachement works, but now I'm only getting a subset of the possible window events.

[eXpl0it3r]

Can you specify why you want to do this? Maybe there's a better way to achieve the same thing.

[mary2409]

sure. I am using the Model/View/Controller design pattern. Controller passes control commands to Model and View. The reason it can talk directly to View is to control the camera in the GL scene. It talks to Model to create and update objects. On any given update, the vertices are passed to View to update the draw.

Currently, I have Controller create a tiny SFML window from which I move the mouse and type to issue Control commands. I realize it looks dirty and it's annoying to have to click in one window and see the result on another window. The reason I can't just move the window event handling to View is because of Modeler. It would be acceptable if I *only* needed to read mouse events to control the camera, but the keyboard events control the objects, so they have to be sent to Modeler.

Since I'm doing 3D, frame rates matter. So I don't want to fiddle with the View to make it now send messages back the other way to Model. I'd rather just have Controller come up as a separate (headless) process, attach to the existing SFML window, read its events, and continue the way it already works.

I feel like this could be a bug in SFML. I'm running Linux Mint 17 with SFML-dev v2.1+dfsg-4ubuntu2.

This link http://www.sfml-dev.org/tutorials/2.0/window-window.php says

"In this case, SFML will create a drawing context inside the given window and catch all its events without interfering with the parent window management."

However, later on it says "the event loop (more precisely, the pollEvent or waitEvent function) must be called in the same thread that created the window"

Can you help reconcile these two statements or confirm whether this is a bug or not ? I get the sf::Window to correctly attach to the window handle, and I get to read some events, but not all events, such as the scroll wheel or mouse click. but mouseMove *does* work. This seems like a bug.

Thanks