Professional UI Solutions
Site Map   /  Register


Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Smooth window resize Collapse All
Subject Author Date
Dominik Braendlin Jan 3, 2011 - 12:38 AM

Dear Tech Support,

In our current application we do have some dialogs that resize according to their content automatically using the e.g. MoveWindow method. Using MoveWindow does not really provide a smooth transition between two different windows sizes.

Using a timer and several calls to MoveWindow to change the size gradually gives a much smoother feeling. I was wondering if this kind of behavior could be implemented directly in e.g. CExtResizableDialog or similar. Do you already provide such a method? If not this support request might be considered a feature request. I am thinking of a method like “MoveWindow” that beside a new window size and position also has a value for the time to change from the old to the new window size and position.



Technical Support Jan 3, 2011 - 11:57 AM

MoveWindow() based transition is not always the best. If window resizing is small (for instance, due to heavy inner controls) then MoveWindow() is not good. It’s possible to make a photo of any window (CExtPaintManager::stat_PrintWnd()), resize bitmap on the screen very smoothly and finally, show resized window at the end of the animation. For instance, all the Prof-UIS popup menu (CExtPopupMenuWnd) animations are based on the popup menu foto transitions - not on the window transitions. In any case, animated resizing can be coded as stand alone function which is applicable to any kind windows, not only to dialogs. The timer based approach can brought surprises because application can potentially shut down or crash during window transition animation. We think such transition animations can better coded using loop and clock()-based measurements of each step’s time. Finally, windows can be layered and non-rectangular. The universal transition animation can be specific for particular layered and non-rectangular windows. Probably that’s why Win32 provides AnimateWindow() as alternative to ShowWindow() and does not provide anything alternative for MoveWindow() / SetWindowPos() / DeferWindowPos(). Even more. Particular tasks require unique transition animations. For instance, expandable menus use animated expanding effect where the initially displayed menu items are sliding and newly appeared menu items are scaled with sliding. And even more. Some windows can become scrollable after resizing or change scroll bar visibility. This should be also handled somehow. We need some additional time to understand how to code a universal animated window resizing.