Forum
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.
|
Subject |
Author |
Date |
|
|
Charles Bisbee
|
Jan 5, 2011 - 5:25 PM
|
My app uses prof UIS 2.92. It has a main dialog with multiple other modeless dialogs all based on CExtNCW < CExtResizableDialog >. This is a port from MFC CDialog application. We are in testing for final release and so this becomes critical for me. When the app is minimized using Windows-M shortcut and then restored using the mouse, the modeless dialogs do not display. They are in position but do not display. The app drags them with it so moving the main window causes a move of the modeless windows and they will appear<o:p></o:p>
The restore works correctly if Windows-Shift-M is used. It works correctly if minimized with the mouse and restored with the mouse. It is only the combination of minimize with Window-M and restore with the mouse that fails. Everything works correctly in the pre ProfUIS application<o:p></o:p>
Please Help
|
|
|
Technical Support
|
Jan 12, 2011 - 8:11 AM
|
You should analyze the WINDOWPLACEMENT data (GetWindowPlacement()) while handling the WM_WINDOWPOSCHANGED message in the main frame/dialog window.
|
|
|
Charles Bisbee
|
Jan 11, 2011 - 5:00 PM
|
Is there a message i can handle that tells me the main window (which works) is being restored. I can then call SetPosition on the other windows. This should work as the SetPosition is what is called when the main window moves. This causes the floating windows to redisplay. Thanks
|
|
|
Technical Support
|
Jan 11, 2011 - 12:30 PM
|
Thank you for reporting the issue. It can be re-produced using Prof-UIS sample applications, Office 2010 applications, Office 2007 applications and the most of any other applications which support a custom non-client area. The custom non-client area requires tricky techniques like removing the WS_BORDER|WS_CAPTION style and handling WM_NC*** messages handling. This is incompatible with system wide Windows commands like Win+M and Win+D. We are not sure if this can be fixed. But we will try to find a workaround.
|
|