On Friday 12 August 2005 20:10, Paul McNett wrote: > Any chance you can send me an example that shows this problem? What > happens when you instead use a straight dTextBox instead of > dDateTextBox. I ask because it could help us figure out where the > problem is...
Looking at the code some more, I see two very different meanings of a control's 'Value': what is displayed to the user, and what is stored/retrieved from the database. In most cases, these values are identical, but in the case of date/datetime values, they can be very different. The dDateTextBox class has an attribute for internally tracking the date, and it uses that to create the Value that is displayed to the user. The problem, though, is that the Value is not in the format needed by the database, and changes to this date cannot be saved. What do you think about changing the flushValue() method to look for a custom method/property in the control that would return the control's actual underlying value (in this case, the date), and this method would by default simply return the Value. This won't break any existing controls, but it would allow us to decouple the display of a control from the value that display represents. Any feelings pro/con? -- -- Ed Leafe -- http://leafe.com -- http://dabodev.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
