Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Change wxMSW to use WidthDefault and HeightDefault for window sizes,

Browse Source 
like the other platforms do.


git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@26099 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
2004-03-05 21:17:06 +00:00
parent 723f8e3a33
commit 426936d182
1 changed files with 22 additions and 29 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
src/msw/window.cpp
View File

@@ -2993,8 +2993,6 @@ bool wxWindowMSW::MSWGetCreateWindowCoords(const wxPoint& pos,
{ {
// yes, those are just some arbitrary hardcoded numbers // yes, those are just some arbitrary hardcoded numbers
static const int DEFAULT_Y = 200; static const int DEFAULT_Y = 200;
static const int DEFAULT_W = 400;
static const int DEFAULT_H = 250;
bool nonDefault = false; bool nonDefault = false;
@@ -3032,36 +3030,31 @@ bool wxWindowMSW::MSWGetCreateWindowCoords(const wxPoint& pos,
this and ignore any attempts to change the window size to the size it this and ignore any attempts to change the window size to the size it
already has - so no WM_SIZE would be sent. already has - so no WM_SIZE would be sent.
*/ */
if ( size.x == -1 )
{
// we don't use CW_USEDEFAULT here for several reasons:
//
// 1. it results in huge frames on modern screens (1000*800 is not
// uncommon on my 1280*1024 screen) which is way too big for a half
// empty frame of most of wxWindows samples for example)
//
// 2. it is buggy for frames with wxFRAME_TOOL_WINDOW style for which
// the default is for whatever reason 8*8 which breaks client <->
// window size calculations (it would be nice if it didn't, but it
// does and the simplest way to fix it seemed to change the broken
// default size anyhow)
//
// 3. there is just no advantage in doing it: with x and y it is
// possible that [future versions of] Windows position the new top
// level window in some smart way which we can't do, but we can
// guess a reasonably good size for a new window just as well
// ourselves
w = DEFAULT_W;
h = DEFAULT_H;
}
else
{
// and, again as above, we can't set the height to CW_USEDEFAULT here
w = size.x;
h = size.y == -1 ? DEFAULT_H : size.y;
// we don't use CW_USEDEFAULT here for several reasons:
//
// 1. it results in huge frames on modern screens (1000*800 is not
// uncommon on my 1280*1024 screen) which is way too big for a half
// empty frame of most of wxWindows samples for example)
//
// 2. it is buggy for frames with wxFRAME_TOOL_WINDOW style for which
// the default is for whatever reason 8*8 which breaks client <->
// window size calculations (it would be nice if it didn't, but it
// does and the simplest way to fix it seemed to change the broken
// default size anyhow)
//
// 3. there is just no advantage in doing it: with x and y it is
// possible that [future versions of] Windows position the new top
// level window in some smart way which we can't do, but we can
// guess a reasonably good size for a new window just as well
// ourselves
if ( size.x == -1 || size.y == -1)
{
nonDefault = true; nonDefault = true;
} }
w = WidthDefault(size.x);
h = HeightDefault(size.y);
AdjustForParentClientOrigin(x, y); AdjustForParentClientOrigin(x, y);