private void ResizeCustomControl(IntPtr hWnd, InteropUtil.RECT rect, params IntPtr[] buttons)
{
DialogUtil.Assume(buttons != null && buttons.Length > 0);
hWnd.AssumeNonZero();
var wndLoc = hWnd.GetWindowPlacement();
wndLoc.Right = rect.right;
hWnd.SetWindowPlacement(ref wndLoc);
foreach (var hBtn in buttons)
{
int btnRight, btnWidth;
m_calcPosMap[hBtn.GetDlgCtrlID()](this, rect.right, out btnRight, out btnWidth);
PositionButton(hBtn, btnRight, btnWidth);
}
//see bug # 844
//We clip hWnd to only draw in the rectangle around our custom buttons.
//When we supply a custom dialog template to GetOpenFileName(), it adds
//an extra HWND to the open file dialog, and then sticks all the controls
//in the dialog //template inside the HWND. It then resizes the control
//to stretch from the top of the open file dialog to the bottom of the
//window, extending the bottom of the window large enough to include the
//additional height of the dialog template. This ends up sticking our custom
//buttons at the bottom of the window, which is what we want.
//
//However, the fact that the parent window extends from the top of the open
//file dialog was causing some painting problems on Windows XP SP 3 systems.
//Basically, because the window was covering the predefined controls on the
//open file dialog, they were not getting painted. This results in a blank
//window. I tried setting an extended WS_EX_TRANSPARENT style on the dialog,
//but that didn't help.
//
//So, to fix the problem I setup a window region for the synthetic HWND.
//This clips the drawing of the window to only within the region containing
//the custom buttons, and thus avoids the problem.
//
//I'm not sure why this wasn't an issue on Vista.
var hRgn = InteropUtil.CreateRectRgnIndirect(ref rect);
try
{
if (hWnd.SetWindowRgn(hRgn, true) == 0)
{
//setting the region failed, so we need to delete the region we created above.
hRgn.DeleteObject();
}
}
catch
{
if (hRgn != IntPtr.Zero)
{
hRgn.DeleteObject();
}
}
}