Ed Leafe wrote: > On Jun 3, 2007, at 7:55 PM, Paul McNett wrote: >> When you explicitly set the size of an object, you also implicitly set >> the MinSize of the object. So, if you explicitly set txt.Width to 300, >> and that txt is part of a vertical sizer with the "expand" flag, or a >> horizontal sizer with a proportion > 0, that txt will never get >> sized < >> 300. I think this is a nice feature/side-effect, but if you have >> something like the class designer saving the width/height of the >> *sized >> at design-time* properties (IOW, the sizer made the textbox have a >> width >> of 312), then this runtime feature doesn't work so well. >> >> Run the two examples of EtypEnum (the cdxml versus the .py version) >> and >> play with sizing the form down to small values, to see what I mean. In >> the .py version, I didn't include the explicit size values (for the >> most >> part), so the user gets well-laid-out smaller sizes. In the cdxml >> version, the controls don't want to get very small so you end up >> getting >> scrollbars instead of lower sizes. > > OK, I remember that quirk in wxPython. > >> I think it is important to let the user specify Width/Height as >> props in >> the class designer, but we somehow have to keep those values from >> getting overwritten by the width as a result of sizer operations. > > I believe that that's impossible. Sizers change the Width and Height > values. Maybe you would like a MinWidth and MinHeight?
Actually, you are half-right: sizers change the reported Width and Height values, but they don't also change the MinWidth and MinHeight values like setting Width and Height explicitly do. MinWidth and MinHeight would be useful properties, probably. However, the current implicit behavior is nice, I think. What about setting some sort of behind-the-scenes userExplicitHeight, userExplicitWidth when the user tweaks the values, as opposed to when the sizer changes them. Then save the user's values (if any) to the cdxml instead of the actual property values... >>> Did you also change the SlotCount for the sizer that contained them? >> Does SlotCount exist outside of cdxml? If so, I wasn't aware of >> that. I >> didn't include SlotCount at all in my Dabo/py conversion. > > No, it is design-time only. But if you remove a panel and don't > change the SlotCount, I'll bet you won't be able to re-open the cdxml > file in the Class Designer. I didn't change anything in the cdxml. I just didn't include some of those panels in my converted-to-python design. >>> Just look at the __init__() for dFormMixin. The same thing happens >>> for MenuBarFile. >> Ok, so they do exist for non-cdxml classes as well. Was there a reason >> we didn't implement these as actual properties? > > Probably because they were added after the fact, as a result of > integrating the DE and MenuDesigner's mnxml files into the Class > Designer, and these were seen as shortcuts to the actual Connection > and MenuBarClass props. After all, what would you expect to happen if > you set the CxnFile prop after the form was live? Should it change > the connection, or just set an attribute? If they aren't supposed to be properties, but instead just arguments to the constructor, they shouldn't start with a capital letter. But they 'feel like' properties, they appear in the propsheet of the class designer, and it wouldn't be bad to say in the docstring "this property has no meaning after the class is fully instantiated". -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/dabo-dev/[EMAIL PROTECTED]
