resize display handling

resize display handling

Edgar Reynaldo

Major Reynaldo

May 2007

I think the best message to handle would be WM_WINDOWPOSCHANGED. It is sent when a window is shown, hidden, moved, or resized, and contains info about the WINDOWPOS in the lParam.

WINDOWPOSCHANGED
http://blogs.msdn.com/b/oldnewthing/archive/2008/01/15/7113860.aspx

WINDOWPOS
http://msdn.microsoft.com/en-us/library/windows/desktop/ms632612%28v=vs.85%29.aspx

EDIT
Trying to understand the comments on this code :

      case WM_ENTERSIZEMOVE:
         /* DefWindowProc for WM_ENTERSIZEMOVE enters a modal loop, which also
          * ends up blocking the loop in d3d_display_thread_proc (which is
          * where we are called from, if using D3D).  Rather than batching up
          * intermediate resize events which the user cannot acknowledge in the
          * meantime anyway, make it so only a single resize event is generated
          * at WM_EXITSIZEMOVE.
          */
         if (d->flags & ALLEGRO_DIRECT3D_INTERNAL) {
            resize_postponed = true;
         }
         break;

I was thinking of doing away with WM_ENTERSIZEMOVE and WM_EXITSIZEMOVE and replacing them with WM_WINDOWPOSCHANGING, but then that would change the current behaviour.

What I am really worried about is this modal loop that the comment above is talking about.

I tried only generating an event on WM_WINDOWPOSCHANGING but in D3D for some reason all the ALLEGRO_EVENT_DISPLAY_RESIZE events get backed up until you stop resizing the window. That may be the modal loop effect from above.

Not sure where to go from here...

Edit2
Somehow my changes corrupted all the title bars on all my windows. Yeah, Aero is corrupted somehow. I'm gonna reboot and hope it gets fixed.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

Thomas Fjellstrom

Member #476

June 2000

Yeah, I'm betting ENTERSIZEMOVE's default (windows provided) handler just enter's a loop to handle the resizing. Not sure, but we could not call the defwndproc on ENTERSIZEMOVE/EXITSIZEMOVE. That might break something though.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Edgar Reynaldo

Major Reynaldo

May 2007

Thomas Fjellstrom said:

Not sure, but we could not call the defwndproc on ENTERSIZEMOVE/EXITSIZEMOVE. That might break something though.

I think that is why the title bars of all my windows got corrupted. I think we have to call DefWndProc, but then it starts that modal loop mentioned above in WM_ENTERSIZEMOVE. Not sure how / if the loop can be broken. I think that is why all of my EVENT_RESIZE's get piled up when using WM_WINDOWPOSCHANGING.