#164 Alignment issues 3.5-RC1

[facelessuser]

I recently upgraded to 3.5-RC1 from 3.3.4 on OSX. I use wxFormBuilder for wxPython 3.0.2. I am seeing some weird alignment issues that seem to be related to a recent request #141.

When creating GUI objects, the parent for the objects used to be done like so:

        self.m_case_checkbox = wx.CheckBox( self.m_search_panel, wx.ID_ANY, u"Search case-sensitive", wx.DefaultPosition, wx.DefaultSize, 0 )

Now they seem to be done like this:

        self.m_case_checkbox = wx.CheckBox( sbSizer2.GetStaticBox(), wx.ID_ANY, u"Search case-sensitive", wx.DefaultPosition, wx.DefaultSize, 0 )

This causes (in some places) things to be aligned very wrong, and no amount of tweaking seems to fix it. The only way I can fix it is to revert all places where the parent was changed above. See attached screenshot.

I don't know if this is related, but maybe this change also affects the formbuilder render? I notice in the formbuilder (where it highlights the selected object with an outline), the "active" highlight border seems to be misaligned. I am not sure if wxformbuilder uses similar logic as shown above to render the borders, but if it does, this is probably related. See other screenshot.

Anyways, currently 3.5-RC1 is unusable form me as I have to manually revert all cases where this new logic is being used to get my application to behave proper.

[facelessuser]

The issue does not seem to occur in Windows (at least not from what I can see). Windows doesn't render a border on the sizer when you click them like it does in OSX, so I can't confirm that either.

I honestly don't understand the original problem outlined in #141 and why the change occured. I know originally it was stated that the frame shouldn't be used as the parent, but the staticboxsizer was desired...I wonder though if this shouldn't be applied when the parent is a panel. I am yet to see problems when using the the panel as the parent with the latest wxPython, but I defintely there does seem to be problems in OSX when the panel is discarded for the sake of of using the staticboxsizer.

[facelessuser]

It appears in my case, I had some custom objects where I was still manually specifiying the old way vs new way. When I changed the custom objects to define the parent the same as its siblings, (matching the autogen way), my problem disappeared on OSX. I will take some time and verify this more today, and if the problem is resolved, then this issue can be closed.

[facelessuser]

Looking through the code generation, I think their are inconsistencies of when staticboxsizer is choosen over the panel, but at least in a given sizer in a given panel they are consistent. For certain groups of elements, the panel is choosen, for certain groups the staticboxsizer is choosen. I personally think this should probably be more consistent, but I can work around it. I also still wonder if we should really be using staticboxsizer at all instead of an available panel.

I will leave it up to you guys to determine whether this needs further investigation or considerations, but I have worked around the issue for now 3.5-RC1 and can use it cross platform now, but it makes it difficult with custom elements to predict when wxFormBuilder is going to use the parent panel or the staticboxsizer for a given group of elements in sizer.

[Michal Bližňák]

Hopefully fixed in wxFB 3.5.2-RC2. Now, the wxStaticBoxSizer contains boolean property called "parent" which tells the sizer whether managed children should be parented to the sizer's static box (required for wxWidgets 2.9.1 and later) or to the sizer's parent instead (default behavior in older wxWidgets versions).

[facelessuser]

Thanks, I will give it a try when it goes live.