Last Comment Bug 322869 - OS chrome isn't correctly hidden
: OS chrome isn't correctly hidden
Status: NEW
:
Product: Core
Classification: Components
Component: Widget: Win32 (show other bugs)
: Trunk
: x86 Windows XP
-- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jim Mathies [:jimm]
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-09 16:17 PST by neil@parkwaycc.co.uk
Modified: 2011-05-23 06:34 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image neil@parkwaycc.co.uk 2006-01-09 16:17:02 PST
Steps to reproduce problem:
1. Create a window of a given width and height
2. Enable transparency

Now, this hides the OS chrome, but improperly, so events still use old client coordinates. The problem is not normally apparent as normally the window's final size is determined after it has been made transparent, and this resize causes a WM_NCCALCSIZE message to be sent, which recalculates the client area.

I believe there is a windows API that forces a WM_NCCALCSIZE message, although I forget whether it is RedrawWindow or SetWindowPos or something else.
Comment 1 User image James Ross 2006-01-10 12:53:49 PST
After playing with SetWindowLong you should use:

  SetWindowPos(hwnd, 0, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE | SWP_NOZORDER |
               SWP_FRAMECHANGED);
Comment 2 User image Jim Mathies [:jimm] 2009-02-04 20:25:18 PST
Neil, would you still consider this to be a valid bug? If not, we'd like to close it out.
Comment 3 User image neil@parkwaycc.co.uk 2009-02-05 01:16:15 PST
It's still technically valid as per comment #1, although I don't remember whether we're "lucky" in that we call SetWindowPos anyway at some point.

Note You need to log in before you can comment on or make changes to this bug.