Windows API SetWindowSize() seems to have no effect - c++

I have what should be an extremely simple goal yet it seems intractable. I have to get some precisely-sized screen pix for documentation so I thought it would make sense to add a control to size my app's window to the exact dimensions I want.
I'm working with VS2010.
Here's the relevant code from my wizard-generated dialog:
DlgSetWindowSize::DlgSetWindowSize(CWnd* pParent /*=NULL*/)
: CDialogEx(DlgSetWindowSize::IDD, pParent)
{
m_width = 0;
m_height = 0;
m_parent = pParent;
}
void DlgSetWindowSize::OnBnClickedOk()
{
CDialogEx::OnOK();
SetWindowPos(m_parent, 0, 0, m_width, m_height, SWP_NOMOVE|SWP_NOZORDER|SWP_NOOWNERZORDER);
}
and here is the call to it:
void CMyAppView::OnWindowSize()
{
DlgSetWindowSize d(this);
if (IDOK == d.DoModal())
{
Invalidate();
}
}
SetWindowPos returns a nonzero value, which indicates success according to the documentation (click here). Of course when running the dialog, I enter the pixel values I want for width and height. The debugger verifies that the expected values are being passed to SetWindowPos, and also that SetWindowPos gives a nonzero return. The bit switches in the last parameter to SetWindowPos are set to ignore the position parameters and only express the size parameters in that call, so that the window should be sized as I want without changing position.
Everything appears to be in order, but the window size doesn't change. I have applied this logic to my app's document window, and when that didn't work, I also applied it to the application's MainFrame window. Zero action.
Am I missing something here, or is there some completely different approach I should be using?

Judging by your use of CDialogEx and the naming convention, I guess you are using MFC, right?
Your call to SetWindowPos() operates on the dialog window itself, as this is a class method.
If you want to call parent's SetWindowPos(), you could do:
m_parent->SetWindowPos(0, 0, 0, m_width, m_height,
SWP_NOMOVE|SWP_NOZORDER|SWP_NOOWNERZORDER);
Also please note that in MFC Document-View architecture, the document doesn't have a window.
Alternatively, you could use Win API call:
::SetWindowPos(m_parent->GetSafeHwnd(), 0, 0, 0, m_width, m_height,
SWP_NOMOVE|SWP_NOZORDER|SWP_NOOWNERZORDER);

Related

Customising a dynamic layout at runtime based on control visibility

I have a multi-purpose CDialog that supports resizing. It can display content in 3 variations.
Variation 1:
Variation 2:
Variation 3:
The dialogue controls are using the dynamic layout settings from the resource editor.
Variation 1 is fine and need no changes.
Variation 2 does not display the combo and date button. As a result I would like the "Text will ..." label to be down at the bottom and the "edit" box to be taller.
Variation 3 has a similar issue where the date button should move to the bottom and the edit box be taller.
Can this be achieved by changing the dynamic layout in code?
Update
I tried this in OnInitDialog:
if (!m_bShowWeekCombo)
{
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
CRect rctNote;
m_staticInfo.GetWindowRect(rctNote);
ScreenToClient(rctNote);
m_staticInfo.MoveWindow(rctCombo.left, rctCombo.top, rctNote.Width(), rctNote.Height());
}
At first I thought it was working:
The note is now at the bottom. But as soon as I resize the window:
The note has reverted to the original position.
I know I have this answer to a similar issue but do I really have to re-build the whole layout?
Update 2
if (!m_bShowWeekCombo)
{
CRect rctEdit;
m_editText.GetWindowRect(rctEdit);
ScreenToClient(rctEdit);
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
CRect rctNote;
m_staticInfo.GetWindowRect(rctNote);
ScreenToClient(rctNote);
//m_staticInfo.MoveWindow(rctCombo.left, rctCombo.top, rctNote.Width(), rctNote.Height());
m_staticInfo.SetWindowPos(NULL, rctCombo.left, rctCombo.top, 0, 0,
SWP_NOSIZE | SWP_NOZORDER);
m_editText.SetWindowPos(NULL, 0, 0, rctEdit.Width(), rctEdit.Height() + (rctCombo.top - rctNote.top),
SWP_NOMOVE | SWP_NOZORDER);
if (m_pDynamicLayout)
{
if (!m_pDynamicLayout->HasItem(m_staticInfo.m_hWnd))
{
m_pDynamicLayout->AddItem(m_staticInfo.m_hWnd,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeHorizontal(100));
}
else
{
TRACE(L"item already has dynamic move/size\n");
}
if (!m_pDynamicLayout->HasItem(m_editText.m_hWnd))
{
m_pDynamicLayout->AddItem(m_editText.m_hWnd,
CMFCDynamicLayout::MoveNone(), CMFCDynamicLayout::SizeHorizontalAndVertical(100, 100));
}
else
{
TRACE(L"item already has dynamic move/size\n");
}
}
}
When I try the above the control width is the original width, even though the dialog had restored to wider dialog width.
CMFCDynamicLayout reads the dialog resource, it stores the coordinates for the child controls as well as their dynamic resize/move properties.
This is all done in CDialog::OnInitDialog. If you move the child control, example, m_staticInfo then CMFCDynamicLayout doesn't know you moved/resized the control. So upon the next dialog resize request, CMFCDynamicLayout uses the old values.
You can add dynamic resize/move for all controls expcept m_staticInfo and other controls which you intend to move manually. Then add m_staticInfo separately:
BOOL CMyDialog::OnInitDialog()
{
CDialog::OnInitDialog();
CRect rctCombo;
m_cbWeek.GetWindowRect(rctCombo);
ScreenToClient(rctCombo);
m_staticInfo.SetWindowPos(NULL, rctCombo.left, rctCombo.top, 0, 0,
SWP_NOSIZE | SWP_NOZORDER);
if(m_pDynamicLayout)
{
if(!m_pDynamicLayout->HasItem(m_staticInfo.m_hWnd))
{
m_pDynamicLayout->AddItem(m_staticInfo.m_hWnd,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeNone());
}
else
{
TRACE(L"item already has dynamic move/size\n");
AfxDebugBreak(0);
}
}
return 1;
}
Internally, MFC calls LoadDynamicLayoutResource(m_lpszTemplateName) to initialize dynamic size/move. But documentation says not to use this method directly.
Clarification
If you are using a dialog that supports resizing then you must remember to calculate the new width and height when you move the control to the new position. You would then use one of the appropriate Size calls. For example:
// The EDIT control height now needs increasing
iNewEditHeight = rctButton.top - iTextMarginY - rctEdit.top;
m_editText.SetWindowPos(nullptr, 0, 0, iNewWidth, iNewEditHeight, SWP_NOMOVE | SWP_NOZORDER);
It is up to you to workout how you want your control initially re-sized.
Then, in OnInitDialog I called a new method:
void CEditTextDlg::SetupDynamicLayout()
{
if (m_pDynamicLayout != nullptr)
{
m_pDynamicLayout->AddItem(IDC_BUTTON_INSERT_DATE,
CMFCDynamicLayout::MoveHorizontalAndVertical(100, 100), CMFCDynamicLayout::SizeNone());
m_pDynamicLayout->AddItem(IDC_STATIC_INFO,
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeHorizontal(100));
m_pDynamicLayout->AddItem(IDC_EDIT_TEXT,
CMFCDynamicLayout::MoveNone(), CMFCDynamicLayout::SizeHorizontalAndVertical(100, 100));
}
}
If you don't set the width correctly when using SetWindowPos and only use SizeNone() it will not resize correctly.

Adding statusbar to CDialog and setting control positions correctly

So, I have a CDialog resource that I have had for a long time and I decided to add a statusbar to it. Here is the resource:
All controls fit nicely in the dialog. Now, at runtime this is what it looks like:
The tutorial I followed was here and for the most part it works. Here is my setup code:
///////////////////////////////
m_StatusBar.Create(this); //We create the status bar
m_StatusBar.SetIndicators(indicators, 2); //Set the number of panes
CRect rect;
GetClientRect(&rect);
//Size the two panes
m_StatusBar.SetPaneInfo(0, ID_INDICATOR_DATE,
SBPS_NORMAL, 200);
m_StatusBar.SetPaneInfo(1, ID_INDICATOR_MEETING_TYPE, SBPS_STRETCH, 0);
//This is where we actually draw it on the screen
RepositionBars(AFX_IDW_CONTROLBAR_FIRST, AFX_IDW_CONTROLBAR_LAST,
ID_INDICATOR_DATE);
GetDynamicLayout()->AddItem(m_StatusBar.GetSafeHwnd(),
CMFCDynamicLayout::MoveVertical(100), CMFCDynamicLayout::SizeHorizontal(100));
///////////////////////////////
I have tried without WindowsBlinds and the issues are still there.
So my issues are:
1/ The controls are overlapping the status bar. How do I accurately set these controls in the resource editor so this issue won't happen? How should it be resolved? Hit n miss?
2/ My dialog supports resizing by using the dynamic layouts and it has the OBM_SIZE in the bottom right:
void CResizingDialog::InitialiseResizeIcon(CBitmap& rBmpResize, CStatic& rLblResize, CWnd* pDialog)
{
CRect rcIcon, rcClient;
if (pDialog != nullptr)
{
rBmpResize.LoadOEMBitmap(OBM_SIZE);
rLblResize.Create(nullptr, WS_CHILD | WS_VISIBLE | SS_BITMAP,
CRect(0, 0, 16, 16), pDialog, IDC_STATIC_RESIZE);
rLblResize.SetBitmap(rBmpResize);
pDialog->GetClientRect(rcClient);
rLblResize.GetClientRect(rcIcon);
rLblResize.SetWindowPos(&CWnd::wndTop,
rcClient.right - rcIcon.Width(),
rcClient.bottom - rcIcon.Height(), 0, 0, SWP_NOSIZE);
CMFCDynamicLayout *pDynamicLayout = pDialog->GetDynamicLayout();
if (pDynamicLayout != nullptr)
{
CMFCDynamicLayout::MoveSettings moveSettings = CMFCDynamicLayout::MoveHorizontalAndVertical(100, 100);
CMFCDynamicLayout::SizeSettings sizeSettings = CMFCDynamicLayout::SizeNone();
pDynamicLayout->AddItem(rLblResize.GetSafeHwnd(), moveSettings, sizeSettings);
}
}
}
How do I avoid the issue that you can see there now in the bottom right?
Update
It looked like I should use CreateEx And use this style SBARS_SIZEGRIP. Then stop creating my own resize icon. I assume the two grippers will look the same. So this might be one of the answers.
I tried using the above flag but unfortunately I can't use it:
This gripper is not consistent with the other one I am using so I need to keep my original one instead.
Update 2
I now realise that the gripper is always created anyway, so I had two grippers there! I have now derived my own statusbar class and switched off the default gripper:
BOOL CCreateReportStatusBar::PreCreateWindow(CREATESTRUCT& cs)
{
BOOL bRet = CStatusBar::PreCreateWindow(cs);
cs.style &= ~SBARS_SIZEGRIP;
return bRet;
}
So now I only have the one gripper. But my two issues still remain.
Update 3
I stumbled over this. In theory if I override this DrawGripper method I should be able to render my own gripper instead. Doesn't work. The method is never called.
Update 4
I decided not to fight the system. I have let the status bardraw the themes gripper and I have adjusted my resizing dialog class to also draw the themes gripper. So all is good.

C++ mouse click on certain spot in window

I have my function here working, but I am certainly going about it the wrong way.
My program uses FindWindow to find the correct window. I need to double click on a specific location on this window.
I made it work by always putting the window in the same location on the screen, but if I moved the window the program would try click on the hard-coded location I have provided and it would not work.
Here is the function:
void lobbyWindow(HWND main_client)
{
//RECT arect;
// GetWindowRect(main_client, &arect);
SetCursorPos(748,294);
mouse_event(MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0);
mouse_event(MOUSEEVENTF_LEFTUP, 0, 0, 0, 0);
mouse_event(MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0);
mouse_event(MOUSEEVENTF_LEFTUP, 0, 0, 0, 0);
}
As you can see I just move the mouse to 748,294 and double click. What I want to do is set the mouse to 100,100 in the main_client window, so if I move the main_client window the mouse still clicks on the correct spot.
Use SendInput() instead, then you can use flags to move the cursor relative to the window -
Input.mi.dwFlags = MOUSEEVENTF_MOVE | MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_LEFTDOWN | MOUSEEVENTF_LEFTUP;
How i can simulate a double mouse click on window ( i khow handle) on x, y coordinate, using SendInput?
http://www.cplusplus.com/forum/windows/97017/
If the window you're clicking in is in another thread/process this approach is fundamentally flawed, because the window can move while you're sending the clicks - meaning even if you have the right position to start with there's no guarantee all the clicks will end up in the same place.
Having said that, you can convert a client-relative coordinate to screen-coordinates using the ClientToScreen API function:
POINT pt = { 100, 100 };
ClientToScreen(main_client, &pt);
Depending on the target window you may find you can simply post it a WM_LBUTTONDBLCLK message to simulate the input at the appropriate position:
PostMessage(main_client, WM_LBUTTONDBLCLK, MK_LBUTTON, MAKELPARAM(100, 100));
SetCursor() requires screen coordinates, so you need to calculate where your double-click would be in screen coordinates relative to the window's current screen location. You can do that by either:
using GetWindowRect() to retrieve the window's current screen coordinates, then offset that by the intended relative coordinates.
use ClientToScreen() or MapWindowPoints() to convert relative coordinates to screen coordinates.
Once you have the intended screen coordinates, you can pass them to SetCursor().

Client rectangle coordinates on screen

How can I get coordinates of a window's client area relative to screen?
I thought about using GetClientRect and ClientToScreen. Also, in a browser window what is ClientRect? Only rectangle with HTML document shown in it, or it includes browser bars and pop-up menus, that can possibly shrink dimension for HTML doc?
I've tried this:
HWND hWnd;
RECT rc;
if (GetClientRect(hWnd, &rc)) // get client coords
{
MapWindowPoints(hWnd, NULL, reinterpret_cast<POINT*>(&rc), 2); // converts rect rc points
return rc.top;
}
But the sad thing is that browser's client rectangle includes all those pop-up browser menus and bars, therefore can't be used to detect accurate coordinates of browsers HTML document space. If anyone got suggestions how it can be done, will try it gladly.
Yes, you can do this with the ClientToScreen function:
RECT rc;
GetClientRect(hWnd, &rc); // get client coords
ClientToScreen(hWnd, reinterpret_cast<POINT*>(&rc.left)); // convert top-left
ClientToScreen(hWnd, reinterpret_cast<POINT*>(&rc.right)); // convert bottom-right
What is the "client" rectangle in a browser depends on the browser implementation. You can use Spy++ to discover this for yourself.
To translate a window's client rectangle to screen coordinates, call the MapWindowPoints function. It implements special handling to always return a valid RECT, even when used in scenarios that involve windows with right-to-left layout:
If hWndFrom or hWndTo (or both) are mirrored windows (that is, have WS_EX_LAYOUTRTL extended style) and precisely two points are passed in lpPoints, MapWindowPoints will interpret those two points as a RECT and possibly automatically swap the left and right fields of that rectangle to ensure that left is not greater than right.
Calling ClientToScreen on both points in contrast fails to account for RTL layouts, and can produce an invalid RECT. It fails to adhere to one of the rectangle coordinate invariants:
The coordinate value of a rectangle's right side must be greater than that of its left side. Likewise, the coordinate value of the bottom must be greater than that of the top.
A reliable function to return a window's client rectangle in screen coordinates would look like this:
RECT client_rect_in_screen_space(HWND const hWnd) {
RECT rc{ 0 };
if (!::GetClientRect(hWnd, &rc)) {
auto const err_val{ ::GetLastError() };
throw std::system_error(err_val, std::system_category());
}
::SetLastError(ERROR_SUCCESS);
if(::MapWindowPoints(hWnd, nullptr, reinterpret_cast<POINT*>(&rc), 2) == 0) {
auto const err_val{ ::GetLastError() };
if (err_val != ERROR_SUCCESS) {
throw std::system_error(err_val, std::system_category());
}
}
return rc;
}
The question update asks for a different, unrelated issue. There is no API built into the system, that allows you to query a web browser's display area for its HTML content. The most promising solution would be to employ UI Automation. The question, however, is too broad to provide a more detailed answer here.
As commented by Raymond Chen, the preferred way of doing this should be something like the following:
inline POINT get_client_window_position(const HWND window_handle)
{
RECT rectangle;
GetClientRect(window_handle, static_cast<LPRECT>(&rectangle));
MapWindowPoints(window_handle, nullptr, reinterpret_cast<LPPOINT>(& rectangle), 2);
const POINT coordinates = {rectangle.left, rectangle.top};
return coordinates;
}
POINT origin;
origin.x = 0;
origin.y = 0;
ClientToScreen(hWnd, &origin);
Now origin is, in screen coords, the top left corner of the client area.
To convert (x,y) from client-area coords to screen coords, add origin.
To do the reverse, subtract.

Draw changeable text with CDC::DrawText

I want to show on the screen some value, that are changeable. I have following code
void CMainWnd::OnPaint()
{
CPaintDC dc(this);
CRect rcText( 0, 0, 500 ,500 );
wchar_t text[36];
unsigned int num = server->GetNumClients(num);
wsprintf(text, L"Number of connected clients: %d", num);
dc.DrawText(text, &rcText, DT_LEFT);
CFrameWnd::OnPaint();
}
void CMainWnd::OnTimer(UINT timerID)
{
SendMessage(WM_PAINT, 0, 0);
}
It draws text when window appears. But in next calls when text is different the text on the screen didn't change. Using the debugger I can see that OnPaint was called, text has been changed, but on my window text remains the same. GetLastError() returns 0. I think I'm missing something important how DrawText works. I tried to call UpdateWindow() in the end, but nothing changed. For some reason screen is not updates..
You should not send a paint message directly, but instead invalidate the area to be repainted (InvalidateRect(&area) ) and let the system handle it. By only sending a paint, you don't get anything because the system says 'There's no area that needs painting, so for efficiency I won't bother' - or rather, the clip area that constrains painting will be empty (no update area). By invalidating an area you tell the system that that area needs repainting, so the next paint call will have a valid clip area and you will see a change.
(Better to use wsprintf_s() with the buffer size - in fact, as you appear to be using MFC use CString and CString::Format() instead - and you should not call the base class OnPaint() (it has no effect, since when the CPaintDC goes out of scope it clears any update area).