SFML with MFC - sf::RenderWindow resize/update issue

[jp]

I use SFML with MFC. I want to keep the ball I draw at the same position/size when resizing the window. I read that I have to use setView() to set the new view according to the new CView window size. I tried it but it did not work directly like instructed on the websites. Then I investigated and got it working with this version (all related code here):

// When I create the window I initialize SFML window in CView class:
sf::RenderWindow sfmlWindow(GetSafeHwnd());
// ...
// Then when I get a WM_SIZE windows message, I do this in its OnSize() handler:
sf::Event event;
while (sfmlWindow.pollEvent(event));
sf::FloatRect visibleArea(0, 0, sfmlWindow.getSize().x, sfmlWindow.getSize().y);
sf::View newView{ visibleArea };
sfmlWindow.setView(newView);
 

I am happy it finally works (took me long time to figure it out ), but... is this really how it should be done (the correct way)?

I have couple of questions:
1) Why do I need to poll all the events in order the RenderWindow to update its size? Also, I was thinking that should the RenderWindow automatically do this update when I resize the window - why it does not change its m_size variable automatically when I resize? sfmlWindow.getSize() will not get updated to the new size if I do not flush the events with the while loop above it. Because I did some reseach: If I do not do that while() loop to poll all the events, the RenderWindow m_size will not get updated to the new size, and I am guessing this is why the sf::view does not get the correct values for the newView.

2) If I always need to empty the sf event queue (like I do above), what is the correct way to do it and where/in which function(s)? Does this issue also occur with other events like mouse events? So if my MFC CView gets a mouse event do I have to first flush the SFML event queue in order the SFML to be in a correct state?

[eXpl0it3r]

SFML requires you to always process events, also when it's embedded in another UI framework (MFC, Qt, wxWidgets, etc).

I'd have to check the code, but could well be that the size is set only when Windows is sending WM_SIZE events and we can't really manually change the internal size, because a) we don't really know what size you're changing the window to until we get the WM_SIZE event and b) the window manager can apply different constraints, e.g. a minimum size, so even if we could track the window size changes, we need to wait for the window manager/OS to tell us, what the size really is.
Whether this can or can't be implemented with a specific call instead of relying on the event is more a design question, but since we currently require the events to always be processed, there isn't really a disadvantage.

[jp]

SFML requires you to always process events, also when it's embedded in another UI framework (MFC, Qt, wxWidgets, etc).

Ok, thanks, good to know. So seems like I was on a right path even though I did not know this .

So, am I doing this correctly by polling all the event in OnSize():

while (sfmlWindow.pollEvent(event));
 

Or is there a better way to handle the sfml events in my OnSize function?

Or should I somehow only poll the size-event and leave others untouched (because in the SFML event buffer there could be other events as well)?

[eXpl0it3r]

You shouldn't just poll during the OnSize handling, but you should always poll.
With that being said, I'm not sure if that works correctly with the MFC setup, since SFML will drain the normal OS event queue, so MFC doesn't get any events to handle

[jp]

You shouldn't just poll during the OnSize handling, but you should always poll.
With that being said, I'm not sure if that works correctly with the MFC setup, since SFML will drain the normal OS event queue, so MFC doesn't get any events to handle

Oh, I think the idea then is that instead of reacting to MFC events (mouse/size) I should poll SFML events instead and react to them. Like I could set a tight timer in MFC View and keep polling there sfml message. Ok, I could try that.