On 3/6/12 11:18 AM, Ed Leafe wrote:
> On Mar 6, 2012, at 10:55 AM, Paul McNett wrote:
>
>> > It probably depends on how easy it is to refactor your class. In vfp it
>> > was a pita to change what class an instance was based on, and frequently
>> > the behavior of the base classes just wasn't ideal and the only way to
>> > override was to subclass. These concerns still exist in dabo but to a much
>> > lesser degree.
> The only reason I can see for this is if you need a distinct behavior
> for some particular class in your application. E.g., you want all textboxes
> to use a certain font, or have forms with a blue base panel, etc. In those
> cases, you would just make a subclass that had that behavior, and then use
> that subclass in your app.
The examples you cite do not, in and of themselves, suggest making a subclass
in
Dabo, although they sure did in VFP. Here's what I tend to do in Dabo:
{{{
lblFontProps = {"FontSize": 9, "FontBold": True}
ctrlFontProps = {"FontSize": 10}
dataCtrlProps = {"DataSource":
self.Form.PrimaryBizobj.DataSource}.update(ctrlFontProps)
...
hs = dabo.ui.dSizer("h")
hs.append(dabo.ui.dLabel(self, Caption="Heh:", **lblFontProps))
hs.append(dabo.ui.dTextBox(self, DataField="name", **dataCtrlProps))
self.Sizer.append(hs)
...
}}}
But I do make composite controls sometimes, which usually involve 2 or more
controls
inside a dPanel. The way the controls interact are contained inside methods in
the
dPanel subclass. Subclassing dPanel makes sense to me in this case.
Paul
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
Searchable Archives: http://leafe.com/archives/search/dabo-users
This message: http://leafe.com/archives/byMID/[email protected]
