Ed Leafe wrote: > On Feb 1, 2007, at 1:27 PM, Paul McNett wrote: > >> Ok, thanks John. This confirms what you said: fields were NULL in the >> backend, they came over as None in Python, Dabo at some level couldn't >> handle it, an error was raised, and the current field values are >> probably something other than None (best guess is the empty >> string). The >> memento would have been filled out in setFieldVal(), and that was >> probably a result of something behind the scenes in Dabo. > > Good work!
Thanks! My guesses turned out wrong in specifics, but I guess overall correct in what was happening. No error was raised; the current field values became something other than None, but not the empty string (u"None"); I didn't say it in the above paragraph but I really didn't even consider at the time that this problem would be coming from the UI layer. The process of writing tests to narrow down where the problem was occurring, while a bit time-consuming, isn't a waste because now we have those tests in place and will notice if some future change messes it up. This fix, and a subsequent one regarding how blank values are gotten for new records, made some existing apps of mine less chatty on the command line, meaning they aren't having trouble anymore figuring out some things that resulted in messages like "couldn't create newval for field..." -- pkm ~ http://paulmcnett.com _______________________________________________ Post Messages to: Dabo-dev@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev
