Probably a regression in GetTotalClientRect

[irwir]

In continuation of my message in the issue "Limit resizing to horizontal / vertical?", see #36 (comment)

The trouble appears only when application was started minimized.

In the dialog resource, progress bar is immediately below the list control (there are buttons below the progress bar and controls above the list).
Two control rectangles were logged in OnSize(), and after reasonable values this was seen:
OnSize List: 6 26 972 493
OnSize Progress: 6 493 972 504
OnSize List: 6 26 6 26
OnSize Progress: 6 -41 6 -30
Negative numbers appear in the call chain after mentioned pView->Create() call with zero rectangle for the window size.
When application window was restored, these values were logged:
OnSize List: 6 52 2200 1087
OnSize Progress: 6 994 2187 1005
On screen, all dialog controls were placed correctly, except the right bottom corner of the list which is too far down and right.
List effectively hides the progress bar and all buttons below, though some buttons and the bar were getting drawn upon the list and could be scrolled with the list contents (looks weird).

Regression testing showed that version 1.5.1 was free from the issue.

Finally, the issue was gone after commenting out these two lines in the current code.

resizablelib/ResizableLib/ResizableFormView.cpp

Lines 132 to 133 in bebab50

	if (!(GetStyle() & (WS_HSCROLL | WS_VSCROLL)))
	return;

[ppescher]

You added those two lines with commit c8b5d86 apparently to "Clear a rare debug assert in CResizableFormView::GetTotalClientRect". Which assert was that? Now you say those lines are not needed, right?

[irwir]

Previously these asserts were easy to reproduce, but have not been seen so far.
Might be that related MFC code have changed.
I will try to see if such assert could happen now.

[irwir]

The old commit was made in the days of VS 2017, and a few things have changed in C++ runtime and MFC.
The assert was considered potentially dangerous because it was related to scroll bars, and there were applications crashing on attempted access to nonexistent scroll bar objects. None were using Resizablelib, though.
Now dozens of attempts never triggered any asserts with the commented out lines.

Strangely, early return does breaks list control which should have scroll bars, but does not break progress bar (control without scroll bars).
So, the condition in the lines 132-133 should go.

Additionally, it might be suggested to change bottom part of the method to this:

	// enlarge reported client area when needed
	if (lpRect->right < lpRect->left + sizeTotal.cx)
		lpRect->right = lpRect->left + sizeTotal.cx;
	if (lpRect->bottom < lpRect->top + sizeTotal.cy)
		lpRect->bottom = lpRect->top + sizeTotal.cy;

	const CPoint offset(GetDeviceScrollPosition());
	::OffsetRect(lpRect, -offset.x, -offset.y);

In optimized release build this code fragment is 1.5 times shorter (and maybe microseconds faster) than the current implementation with temporary CRect.

[irwir]

	if (lpRect->right < lpRect->left + sizeTotal.cx)
		lpRect->right = lpRect->left + sizeTotal.cx;

The conditions can be written even shorter:
lpRect->right = max(lpRect->right, lpRect->left + sizeTotal.cx);

Quite possible, older CPU and codebase were responsible for asserts.
As an example, recently I have got crash dumps, and this happened consistently only for 8th Gen Intel notebook CPU (not in Resizablelib).
Thanks for commiting the fix. Closing this as resolved.