Dynamic Window Size

Okay, I've come up with this:

1
2
3
4
5
6
7
8
9
10
void SizeWindow(HWND& hMain, int iWidth, int iHeight)
{
  RECT clRect, clWin;
  clRect.right=iWidth;
  clRect.bottom=iHeight;
  GetWindowRect(hMain, &clWin);
  AdjustWindowRectEx(&clRect, WS_OVERLAPPED|WS_BORDER|WS_SYSMENU|WS_CAPTION, FALSE, WS_EX_CLIENTEDGE);
  MoveWindow(hMain, clWin.left, clWin.top, clRect.right, clRect.bottom, TRUE);
  return;
}


Theoretically, with this function I could pass in two variables to use as width and height of the window's client area. It would then get the window's current size with GetWindowRect(), adjust the window size with AdjustWindowRectEx() based on the values passed in, then set the new size with MoveWindow(), correct?

Essentially, I was looking for some opinions on the pros and cons of this type of implementation. Is it a bad idea, and why? If not, what could be some good points of doing this?

Second, how about disabling the ability to change window size by pulling the window edges, and only setting a couple of different window sizes using this function that the user may choose from? Would people dislike not being able to control exact window size?

Edit: I maybe should have tried actually using that function beforehand, because it doesn't work as intended. However, the following fix does:
1
2
3
4
5
6
7
8
9
void SizeWindow(HWND& hMain, int iWidth, int iHeight)
{
  RECT clRect={0, 0, iWidth, iHeight};
  RECT clWin;
  GetWindowRect(hMain, &clWin);
  AdjustWindowRectEx(&clRect, WS_OVERLAPPED|WS_BORDER|WS_SYSMENU|WS_CAPTION, FALSE, WS_EX_CLIENTEDGE);
  MoveWindow(hMain, clWin.left, clWin.top, clRect.right-clRect.left, clRect.bottom-clRect.top, TRUE);
  return;
}


Questions remain the same though.
Last edited on
Well, I don't have any problem with controlling your window sizes, so long as what you do works for the application. If you set the style for a window to only WS_VISIBLE (as opposed to WS_OVERLAPPEDWINDOW or something like that), the user won't be able to resize it with the mouse.

Otherwise, your code above should more or less work once you have it debugged (I didn't look at it close, but MoveWindow and SetWindowPos affect screen sizes, locations, and z order).
freddie1 wrote:
If you set the style for a window to only WS_VISIBLE (as opposed to WS_OVERLAPPEDWINDOW or something like that)

Actually, that was what I was referring to with:
and only setting a couple of different window sizes using this function that the user may choose from?


If you, for example, only have the flags used in AdjustWindowRectEx() set for the window style parameter of CreateWindowEx(). With those flags, the user may not resize the window with the mouse. Or, maybe add in the flag WS_MINIMIZEBOX, because I know people like to minimize programs to get them out of the way.

I was asking though, would only being able to choose from a few different sizes using this (as opposed to WS_OVERLAPPEDWINDOW resizing) considered to be annoying?

The function was originally just pulled from my head. I haven't actually gone through and fully tested/debugged it, but it was mostly just a visual aid for the main question.
Maybe you should think about handling WM_GETMINMAXINFO message to provide minimum and maximum size for your window and let the user resize the window normally, it will be not be able to resize outside these ranges.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms632626(v=vs.85).aspx
modoran wrote:
Maybe you should think about handling WM_GETMINMAXINFO message to provide minimum and maximum size for your window and let the user resize the window normally, it will be not be able to resize outside these ranges.

That's definitely an option.

I was kind of asking more theoretically, what does everyone here think of the idea? If it were in a program you downloaded (or got from somewhere) would you like it/dislike it, and why?

How would you feel about a window that you can't manipulate the exact size of? How would you feel if there were only a few specified sizes to choose from?
Topic archived. No new replies allowed.