Change wxMSW to use WidthDefault and HeightDefault for window sizes,
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:
@@ -2993,8 +2993,6 @@ bool wxWindowMSW::MSWGetCreateWindowCoords(const wxPoint& pos,
|
||||
{
|
||||
// yes, those are just some arbitrary hardcoded numbers
|
||||
static const int DEFAULT_Y = 200;
|
||||
static const int DEFAULT_W = 400;
|
||||
static const int DEFAULT_H = 250;
|
||||
|
||||
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
|
||||
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;
|
||||
}
|
||||
w = WidthDefault(size.x);
|
||||
h = HeightDefault(size.y);
|
||||
|
||||
AdjustForParentClientOrigin(x, y);
|
||||
|
||||
|
Reference in New Issue
Block a user