Forum

Our application, compiled against ProfUIS300n.dll, misbehaves in the following way.  (I am able to reproduce using an unchanged compile of ProfStudio for ANSI Release targeting.)

Required Setup:

1. Windows 7 Professional, [Version 6.1 build 7601].


2. Dual Monitors, workspace extended across both monitors horizontally.  Primary monitor is Monitor #1 and is leftmost.  Secondary monitor is Monitor #2 and is on the right.  Both monitors are identical: same model, size, resolution, etc.


3. Display personalization configured with a "Windows Classic" - based scheme.  NOTE that the bug only occurs for these legacy schemes and not for Aero-based schemes.

1. Start Application.


2. Move application to the second monitor (the one on the right).


3. Maximize the application.


4. Minimize the application.


5. Un-minimize the application.  Bug: the application restores such that the left coordinate of the app’s outermost window is 1 pixel beyond the right edge of the viewable area.  [e.g. if both monitors are set at 1280 x 1024, then the viewing area is from (0,0) to (2559,1023), and the upper left corner of the application ends up at (2560,0) ]  This is outside the viewing area, so to the user, it seems the application has "flown away."  :-/

Thanks!

-- john baldwin

Software Development

Bond International Software

Haven’t heard back from you guys since the end of June.

Were you ever able to solve the problem?

Still looking at this.
We will respond when we have it fixed.
Looks like mid next week.
Prof-UIS Support

Any news or progress?

Thanks for keeping me in the loop!

I thought I’d have some time to trace through the debugger myself, but things have been pretty busy.
If I get the chance, I’ll try to do a little of that next week.

Confirmed "plain vanilla" MFC sample applications do not have this problem.

Hope this helps!
--JTB

Hi The support person that this was assigned to does not have two monitors that are the same. But here was his reply from the fist post.

1. An application MFC based (not using profuis) doesn’t have this problem ?
2. In “ExtNcFrame.cpp” line 3777 – case WM_SYSCOMMAND – will be a good point to start debugging and tell as if is something wrong there.

We will not get to this until late tonight or early tomorrow.
We have a similar hardware configuration here at TSELLC.
So we will test it here.

Support@Prof-UIS.com

Thanks very much for the prompt reply!

I have some more information which may (or may not) be helpful to you.

After reproducing the problem, I added a message handler, void TSSMainFrame::OnWindowPosChanged( WINDOWPOS* lpwndpos ) dispatched in the message map by ON_WM_WINDOWPOSCHANGED().

On un-minimize, it (eventually) gets called with lpwndpos->x == 2560 (see monitor configuration above), y==0, cx==1280, cy==1023, and flags==55 (decimal)...

...and when that happens, a breakpoint on line 1498 of "ExtNcFrame.cpp" shows that a call to pWndFrameImpl->GetWindowRect( &rcWnd ) results in rcWnd.top==0, .bottom=1023, .left=2560, and .right=3840.  [This is in CExtNcFrameImpl::NcFrameImpl_SetupRgn(WINDOWPOS * pWndPos // = NULL ) .]



So I guess by that time the winrect has been set wrong.

The has been no fix for this in 3.01.
The support team will look at this and get back to you in a day or two.
Prof-UIS Support