Forum

I tested DRAWCLI sample.

I have following monitor settings:
[ 2 ] [ 1 ]
1 - primary monitor, screen coordinates: 0,0 x 1280,1024
2 - screen coordinates: -1280,0 x 0,1024

When i restore DRAWCLI main window from minimized state (click app button on task bar) it always appears on left (2) monitor though initially it was on right primary (1) monitor.

I looked at code and saw that in
CExtNcFrameImpl::NcFrameImpl_SetWindowPlacement() to determine in which monitor you should mazimize window you use following method:

void CExtPaintManager::stat_GetMonitorParms(
    monitor_parms_t & _mp,
    HWND hWndFrom
    )
{
ASSERT( hWndFrom != NULL && ::IsWindow(hWndFrom) );
RECT rcWnd = { 0, 0, 0, 0 };
VERIFY( ::GetWindowRect( hWndFrom, &rcWnd ) );
stat_GetMonitorParms( _mp, rcWnd );
}

But GetWindowRect() for minimized windows always returns rect with -32000 coords.
{top=-32000 bottom=-31969 left=-32000 right=-31840}
I don’t know why it work in this way.
Then you call MonitorFromRect() which
"..retrieves a handle to the display monitor that has the largest area of intersection with a specified rectangle.." (from msdn)

So for my case it will always return left (2) monitor.

The desktop manager works well with default looking and behaving windows. It does not work correctly with skinned windows. The problem is not with the re-painted non-client area. The problem has to do with the re-computed non-client area when the WS_CAPTION style is removed. The skinning subsystem in Prof-UIS completely re-computes the non-client area for best skinning look and re-paints it. It also removes the WS_CAPTION style from the window because non-client areas of windows marked with this style become painted by Windows not through window procedure. In some situations Windows paints non-client areas of desktop windows manually without notifying them and this is absolutely not acceptable for skinning. Unfortunately there are no notifications for desktop window re-positioning commands invoked from the task bar. This problem is still at the research stage.

Dear Technical Support,
I encountered the same problem that our customer complained about this bug.

To reproduce this problem,

1. Use Office 2007 theme, maximize the application window size.
2. switch to desktop using "Show Desktop" command in Quick launch, then click the application back to front on the task bar.
3. The application window size will be restored as normal window size but not maximized.

Could you help us to fix this problem in Prof-UIS (include how to update the source code) for our customer?

Best Regards,
Thomas

I discovered that thi issues is reproduced only with Office 2007 Theme (any of three). Please try again with this theme.
I could stably reporduce this issue on three computers.

Also i found another related bug but more serious. It doesn’t depend on monitor’s count and is also reproduced only with Office 2007 Theme.
Maximize main window (e.g. DRAWCLI sample).
Click "Show Desktop" on Quick Launch. Click on DRAWCLI window button on tsak bar - main window restored with NOT maximazed state.

We failed to reproduce this problem. All the sample applications work correctly in the same double monitor configuration. We checked this on Windows Vista Enterprise and Windows XP Professional with Service Pack 2, both systems are 32-bit. We believe the behavior may be hardware specific.