On Jun 1, 2007, at 6:43 PM, Paul McNett wrote:
> I'm using this as a project to understand the cdxml format, and have
> noted some questions/possible defects in my mind so far because of the
> exercise:
>
> + Grid columns apparently put all property values into the cdxml,
> whether or not they were changed from the default.
This one is unusual, but looking back at the code, I don't remember
why. Here's the code in question from the LayoutSaverMixin class in
ClassDesignerComponents.py
if isinstance(self, dabo.ui.dColumn):
# We need all props for this class.
allProps = True
I'll look into what would happen if these lines were removed.
> + The sizerInfo attribute stuffed into each and every object added
> appears to mostly have default values, such as BorderSides=["All"] and
> Border=0. The default stuff should not be part of cdxml.
This is a known limitation that comes when you have to handle
inheritance. You can't just assume that something is different than
the default setting; you have to determine if it is different than it
was in its superclass. There is a lot of code that deals with this
for controls and their props; but for sizerInfo stuff hasn't been
done yet.
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.
> + Seems that Width, Height, Left, and Top are always saved, whether or
> not they are relevant for the given object. For example, your dPages
> have these properties, which really makes no sense because a given
> page
> will be positioned inside the pageframe and take up all the space
> it is
> given in that context. This could be bad elsewhere too, such as with
> grids and textboxes, because by explicitly setting Width and
> Height, you
> are also implicitly setting the minimum size which could have
> aggravating results with sizers at runtime (the design will only
> resize
> down to everyone's aggregated minimum size, bringing in the
> scrollpanel's scrollbars prematurely). To be clear, Width and
> Height are
> relevant because of this but it seems to me you have them set pretty
> high - whether you set them explicitly high or whether they just got
> saved that way because that's how big the sizer made them in the
> designer, I don't know. If the latter, I think it is a defect.
Well, this ties in to the previous matter. What is done is that
every property that is different than the default for that class is
saved. Pages, being panels, have a default size of (0,0), so yeah,
they get saved.
There used to be code that filtered these properties out; when it
was changed I left it as a comment, which means I wasn't sure that
this was the best approach. Here is the code where properties that
are not to be saved get weeded out:
for prop in desProps:
if prop.startswith("Sizer_"):
continue
if prop in propsToExclude:
continue
if (hasSizer or isinstance(self, dabo.ui.dPage) or
isSplitPanel)
and prop in ("Left",
"Right", "Top", "Bottom"): #,
"Width", "Height"
continue
if prop == "BackColor" and isinstance(self, (LayoutPanel,
LayoutSpacerPanel)):
continue
I don't remember what the trade-off here was, but apparently
something was getting screwed up by not including these properties.
If you can find a case where the inclusion of these properties is
causing a problem, let me know.
> + I notice several layout panels in the design, and sizers in the
> hierarchy that aren't really necessary to get the desired layout.
> Probably a necessary evil (benefits of having sizer slots as a visual
> element during the design outweigh the possible excessive number of
> sizers/layout panels). I removed a couple obviously-unnecessary layout
> panels.
Did you also change the SlotCount for the sizer that contained them?
Designs are supposed to be re-entrant; you can start working on
something, save it, and then re-open it just as it was when you left.
I don't know how you would imagine restoring a panel that may have
modified sizer settings without including that panel in the design.
As far as the "unnecessary sizers" are concerned, I'd have to see
that design to understand why that happened. Sounds more like poor
execution than something structural. There's no way for me to
implement DWIM().
> + There are some properties of the form that don't exist in raw Dabo,
> and perhaps they should: CxnFile, and CxnName. I don't really
> understand
> how these come into play at runtime, though.
Just look at the __init__() for dFormMixin. The same thing happens
for MenuBarFile.
-- 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]
