Sometimes I still end up needing to manually nest sizers, and handle it myself; but most of my UI rewrites now use a sc.SizedPanel or sc.SizedFrame .
BTW, is there a way I can see some of the cases that SizedControls don’t handle? I know they won’t handle every case yet, but I’d like to see if there are ways I could adapt them to handle more.
I’ll dig through and see if I can tear out some of our Custom Stuff to make a general example or two. Our “global search” dialog is one example: it displays extremely custom search criteria for users, inspired by some configuration dialogs on the mac (like Spotlight) but customized more (and being able to OR). Its just a darn complicated window: it is scrolled, has multiple “group” panels which have a “title” panel, then any number of “Condition” panels within that can be dragged and dropped between groups and deleted independently. “Condition” panels are Field, Operator, and Value… with Value being custom so that if you’re searching on a date field, you have a date-range in the control, stuff like that.
The UI for the window has given me quite a bit of trouble 
Attached is a screenshot to better explain what the heck is being done. In the given example, it wants to find all things in our system that EITHER matches (slug contains “this word” AND field3 matches “this pattern*”) OR (field2 is “This value”). I like the idea of the window and it mostly works, and its -completely- generic. But its a pain.
And a bit of an oddity – so not using SizedControls with it seems not to be a failing of the SizedControls.
Looking over the code, I think in most cases I did a manual nested-sizes situation I could have done it differently by nesting new panels. I don’t know really if thats better, though, except to have a consistent configuration and HID considerations.
For example, on one dialog I have a long narrow bit; on the top of this bit is a FlexGridSizer for a series of labels and controls… then a toolbar, and a big ol tree control. To accomplish this, I had a master BoxSizer to which I added a FlexGridSizer first, and then to the grid all of my key/value controls, then adding the toolbar and the tree.
I could have created a sub-SizedPanel to host the key/value controls, and then add that as the first child to my main panel… and maybe should have. But SizedControls were new to me and I was used to having to do nested sizers to get things to look the way i need.
Of course, setting the border with the Sized controls for cases where I do want to give additional information is a pain. I never remember the format off the odd argument. I think Imma gonna make a Border function that takes Border(all=5) or Border(left=5, right=5) and turns them into (“all”, 5) and ( (“left”, 5), (“right”,5)) respectively to maintain readability and sanity.
I considered implementing something like this, but currently it wouldn’t work like you’d expect it to. Border(left=5, right=5) will work fine, but Border(left=5, right=8) will not work as you expect - you’ll end up with both left and right borders being either 5 px or 8 px (or only one border being set), depending on how it is coded. This is because I’m just wrapping wx sizers, which only store one value for border size - it does not store separate border sizes for each direction. This is IMHO confusing and non-intuitive, but that’s how sizers work, and I haven’t had time to improve upon it yet, as it’d have to be done at the C++ level, which requires a lot more work to write and test.
Well, yes-- I wasn’t thinking when I made the example. I knew that, honest! Just… forgot But the current syntax is just painful. I’ll do something to wrap it, even if its Border(5, left=True, right=True) like that. Something that doesnt’ make me have to remember the order and syntax of the tuple that comes out. In fact I like that syntax, so will probably end up using it. Something to make it appear more explicit.
–Stephen
