On Nov 19, 2007, at 12:14 PM, VGSoftware wrote:
> Ed, you introduced a bug in the fix i sent you with the dabo.errorLog
> change, here is the fix:
>
> dTextBoxMixin.py must read:
> dabo.errorLog.write(_("Error setting value to '%(strVal)s: %(e)s") %
> (self.Application.str2Unicode(strVal), e))
>
> I know it is hard to you to always be alert to this kind of
> problems...but they really screw the day of the really newbie
> developers, i'll try to track them down as much as possible and
> provide
> the fixes... they really are trivial...
It's difficult when things work 99% of the time for me, but not for
those who use more than ASCII regularly. I've fixed that line (your
code has a bug, too!); please let me know about any other places
where you find problems.
> BTW, i'd like to propose something... i think sometimes it is
> usefull to
> be able to choose if i want to save the value or the maskedValue of a
> dMaskedTextBox, don't you?
>
> The implementation doesn't seem that hard, i think i can do it
> myself if
> you agree with it....
I haven't worked with data in masked textboxes very much, but in
general the mask is for the user's benefit, and not actual data.
E.g.: phone numbers in the US are commonly displayed as: (123)
456-7890. The parentheses, dash and space are not part of the number;
they just make it easier to read. And since they are not part of the
actual data, but are just a formatting convenience, they don't belong
in the database. This allows alternate formatting (I prefer
123.456.7890 myself) without any change to the data.
But let's assume that there is a good use case for storing
formatting (I can't think of any). I'm not sure how the masked
controls would handle setting values in these cases. What I mean is
that if the mask is "(###) ###-####", and the data is "1234567890",
the control handles that as expected, placing the numbers where the
'#' symbols are. But what if the data were "(123) 456-7890"? Wouldn't
the masked control see the non-numeric values, and throw an error?
> I've been using my own homegrown dabo version for a while... but i've
> concluded this is not feasible....
For the reasons I mentioned? Or was there something else?
> so i'm reworking my code to the new
> dado features included...and bugfixing the official dabo when
> needed...
Keep those bugfixes coming!
-- Ed Leafe
-- http://leafe.com
-- http://dabodev.com
_______________________________________________
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/dabo-users/[EMAIL PROTECTED]
