sf::Event::Resized also while the user is still resizing?

[vanisher]

Howdy,

Is it possible that SFML also sends an sf::Event::Resized (or name it sf::Event::Sizing or whatever) if the user is still engaged in resizing the Window but hasn't released the mouse button yet?

I'd like to update the Window on every little size change so it would immediately give the user a preview while she's deciding about how large/small it shall get. Also, it might make it possible to catch sizes which are not supported by the application (too small or bad x/y ratio etc.) while the user is resizing the window.

Of course, this feature would not necessarily be guaranteed to work on all operating systems SFML works on, but then, SFML could support it if the system does. For example, Win32 sends WM_SIZING messages in this case.

Keep up the good work..

[Laurent]

Is it possible that SFML also sends an sf::Event::Resized (or name it sf::Event::Sizing or whatever) if the user is still engaged in resizing the Window but hasn't released the mouse button yet?

No, this is technically impossible with the current architecture of SFML, because the OS blocks the current thread during the whole move/resize operation. So you can only receive a Moved or Resized event after it's finished.

There are already a lot of topics about that on this forum.

[omeg]

Is it possible that SFML also sends an sf::Event::Resized (or name it sf::Event::Sizing or whatever) if the user is still engaged in resizing the Window but hasn't released the mouse button yet?

No, this is technically impossible with the current architecture of SFML, because the OS blocks the current thread during the whole move/resize operation. So you can only receive a Moved or Resized event after it's finished.

There are already a lot of topics about that on this forum.

This is actually incorrect - Windows doesn't block the current thread during resize/move operations by itself.

This is a boilerplate "empty window" example with following window procedure (single threaded of course):

Code: [Select]

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_DESTROY:
PostQuitMessage(0);
break;

case WM_SIZING:
{
RECT* r = (RECT*)lParam;
wsprintf(buf, L"WM_SIZING: (%d,%d-%d,%d)", r->left, r->top, r->right, r->bottom);
OutputDebugString(buf);
}
break;

case WM_MOVING:
{
RECT* r = (RECT*)lParam;
wsprintf(buf, L"WM_MOVING: (%d,%d-%d,%d)", r->left, r->top, r->right, r->bottom);
OutputDebugString(buf);
}
break;

default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}


[Laurent]

This is actually incorrect - Windows doesn't block the current thread during resize/move operations by itself.

This is correct -- windows does block the current thread

Basically, Windows starts an endless loop that calls your message handler, but it only returns to the caller (ie. your code) when it has finished.

Code: [Select]

while (resizing)
{
    CallWindowProc(hwnd, WM_SIZING, ..., ...);
}
So the message handler is called, but in a blocking loop.

And since SFML doesn't use callbacks to forward events to the user, you have no choice but to wait until the internal loop is finished, and finally have a chance to call PollEvent.

[omeg]

Ah yes, if you are not using callbacks then you are right. I wish the whole message queue thing was more straightforward.

[vanisher]

I see. Sorry if i didn't see previous threads on the subject.

Thanks for the detailed answer, though.