I personally think we should do it the way Qt does it and have several different text boxes. I know this might play havoc a little with the app wizard and existing databases, but I think it is the way to go. For example, people use textboxes for numbers all the time, maybe even more than masks, so doesn't it make sense to break that out and create a dNumTextBox. The point I am trying to make is that in the current implementation the dTextbox is all encompassing and as a result you lose the ability to add feature for specific types of data that make a developers life easier. For example, setting a range property and having a textbox automatically validate whether or not the number is in range.
So, why not use a generic dTextbox with just the text based functions (no value conversion, etc.) and then throw the specified functionality into subclasses (similar to how we are doing it now with dDateTextBox). We can still check to see if it's a textbox by whether or not it inherits from dTextbox, so I don't think it should break functionality. My $0.02. Cheers, Nate L. On Nov 16, 2007 6:33 AM, Ed Leafe <[EMAIL PROTECTED]> wrote: > I've been playing around with solutions to the current dTextBox > problem with the Mask property. Needless to say, the current > implementation is wrong, so we need both a short-term fix and a > longer-term solution. For the short-term fix, I propose making a > dMaskedTextBox subclass, in the same way that we have dDateTextBox. > This will break any current code that creates textboxes with a Mask > property in the constructor, but the fix is relatively trivial, so it > shouldn't be too painful. Longer term, there are several options. > > I first considered defining dTextBox as a non-GUI class that would > create the correct textbox on the fly as needed. This would allow the > control to be created without a mask initially, and then have one > added later; the controlling object would simply copy the properties > of its current control, destroy that, and instantiate the new control > with the same properties of its predecessor. We would then have to > use some of the __getattr__/__setattr__ magic to pass code from the > proxy wrapper to the actual control, so that, say, setting the Value > of the proxy object sets the value of its underlying GUI control. > > The problem with this approach is that a solution would have to be > found to the problem best exhibited in this code: > > txt = dabo.ui.dTextBox(self, ...) > self.Sizer.append(txt) > > In this example, 'txt' is a reference to the non-GUI proxy, and > trying to add such an object to a sizer will simply not work. We > could possibly modify the sizer classes to check for proxy objects > and, if found, add the underlying control, but then references to the > sizer's child objects will no longer be correct. Also, I'm sure that > there are other such cases where dealing with a non-GUI proxy > reference will cause problems; this was just the one I ran into while > trying out this approach. > > So I thought that maybe I would make the proxy a panel, and > dynamically add the correct textbox to it. This gets around the sizer > issue above, but introduces all sorts of other complications, since > the GUI containership hierarchy is now changed. > > My other idea was to use metaclasses to have Dabo dynamically create > the correct inheritance on the fly. I haven't worked with metaclass > programming in a while, so I'm a bit rusty, but I'm reading up on it > to refresh my memory. I'm not sure if this is even feasible, so if > anyone who is versed in metaclass programming can shed some light on > this (and maybe save me some wasted effort!). > > If anyone else has suggestions, I'm listening! > > -- Ed Leafe > -- http://leafe.com > -- http://dabodev.com > > > > [excessive quoting removed by server] _______________________________________________ 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]
