On Windows, it seems to work perfectly fine now. There was a conflict between AWT and SFML in that both registered their own window function. The solution I came up with was to create my own window function that passes all events to both AWT and SFML.You don't have to do that. On Windows, when you register your event callback, it is inserted in the chain of other existing callbacks (if you do things right), so you don't have to care about other potential systems that use an event callback on the window. Just look at how SFML does ;)
You don't have to do that. On Windows, when you register your event callback, it is inserted in the chain of other existing callbacks (if you do things right), so you don't have to care about other potential systems that use an event callback on the window. Just look at how SFML doesBoth SFML and AWT wrote the "GWLP_WNDPROC" and "GWLP_USERDATA" fields and both expect their respective data in it. That failed, I had to fix it.
Both SFML and AWT wrote the "GWLP_WNDPROC" and "GWLP_USERDATA" fields and both expect their respective data in it. That failed, I had to fix it.GWLP_USERDATA is a window property and there's only one, so yes you have to find a workaround.
And I'm assuming something similar to break input events being passed to SFML on LinuxAs I said I don't remember how things work on Linux, so you have to look at the source code (of SFML). I can have a look if you're really stuck.
I suppose I would still have to poll events from the RenderWindow to make sure that the buffer doesn't fill up? Or isn't that a problem?I'm not sure. If you don't call pollEvent, SFML doesn't trigger internal event processing, but AWT probably does it and my event callback gets called anyway. That's for Windows at least, on Linux there's no registered event callback so nothing can happen automatically, and I have no idea about OS X.