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: Dabo-users@leafe.com

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/4F566525.4020108@ulmcnett.com