Bug #19027 2013-06-17 08:27

anzv

WYSIWYG failure with wxScrolledWindow

When working with wxSmith's visual editor, I am Not Seeing What I Get for certain very simple control/sizer structures involving wxScrolledWindow as a leaf. Examples:

1) wxFrame > wxScrolledWindow

2) wxFrame > wxBoxSizer > wxScrolledWindow

3) wxFrame > wxPanel > wxScrolledWindow

4) wxFrame > wxPanel > wxBoxSizer > wxScrolledWindow

5) wxFrame > wxBoxSizer > wxPanel > wxScrolledWindow

6) wxFrame > wxBoxSizer > wxPanel > wxBoxSizer > wxScrolledWindow

If none of the elements on these paths have siblings, then the whole frame will be contracted to 32x32 (or something like that) in the visual editor, regardless of the frame's default size setting. The frame will not react to being resized with handles, and neither will the nested controls (the wxScrolledWindow and the intervening wxPanel if present). Manually editing the controls' properties like size or minimum size has no effect either. This is not the case in the running application, where the size of the frame is honored, and no collapsing is observed. This is what I understand as "What I Get".

Expected behavior: What I Get.

Actual behavior: the wxScrolledWindow, and the entire frame, collapses to 32x32 (or something), and no amount of fiddling with size, default size, minimum size etc. properties in the properties editor will make it actually grow in the visual editor, regardless of whether I set these properties on the wxScrolledWindow, the wxFrame, the intervening wxPanel, or all of them.

Window/sizer structures tried:

Needless to say, at least 1) and 2) work as expected in the application: the frame is not collapsed when I run the program, it has a default size. Actually

Category

Plugin::wxSmith

Group

Platform:All

Status

Open

Close date

 

Assigned to