On Jun 3, 2007, at 7:55 PM, Paul McNett wrote:
>> What this means is that if you have, say, a panel class and define
>> the sizer settings on one of its objects, and then use that class in
>> another class, you see the sizer set the way it was in the
>> superclass. Now if you go back and change the sizer settings in the
>> superclass, save that, and then open up the subclass/instance, it
>> still shows the original settings.
>
> I don't follow this paragraph... The sizerProps are merely helpers for
> how to execute the append() call, right? IOW, they don't specify the
> actual properties of the containing sizer.
No, they are set separately by passing to
obj.ControllingSizer.setItemProps(). They specify properties of the
sizer *item*, not the sizer.
> The inclusion of them for dPage isn't really a problem, and not the
> gist
> of my comment. The real problem could very well be in Dabo itself, but
> it's been this way for ages, and it exists in wx too:
>
> 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?
>> 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.
>> 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?
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.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]
