Now that I know how it work, I like the current functionality. My goal was to minimize screen "flashes" as the system updates info, which actually really slows down system responsiveness. I don't want to unFreeze until the top most unFreeze is fired.
I agree with Nate in that it would be great if we could turn off the dabo trapping so we can see the original cause of an exception. Larry Long -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate Lowrie Sent: Tuesday, June 19, 2007 12:55 PM To: Dabo Users list Subject: Re: [dabo-users] Lockdisplay On 6/19/07, Ed Leafe <[EMAIL PROTECTED]> wrote: > On Jun 19, 2007, at 12:21 PM, Paul McNett wrote: > > > But, I also recognize that, as an overarching framework, we can also > > make our user/developer lives easier by trapping and handling > > exceptions where we know how the person would want to handle it. The > > problem is, this is a fuzzy line and everyones fuzz is different. > > > > So, I'm not really pushing for anything different right now, but > > perhaps I'm starting to think about ways to have our cake and eat it > > too. A dabo.settings.trap_exceptions flag could work... > > > > As a developer of Dabo, I personally get quite annoyed every time I > > need to track down a QueryException raised my my bizobj, which could > > have started out as a python TypeError buried way down in some > > obscure dCursorMixin method. If we had just let the original > > exception propagate, instead of trapping it and changing it, the > > debug cycle wouldn't be so convoluted. > > That's a good example where silently trapping an error causes > more harm than good. Those should obviously not be silenced. > > I draw a distinction between errors that are the result of > something done wrong, and errors that are the result of arbitrary > design decisions. In the case of wxPython's Freeze/Thaw > implementation, there is no reason why calling Thaw() should ever > throw an error. I actually first implemented this as a DisplayLocked > property, but changed to the stacked method call implementation > instead. But had I done it as a property, would you expect this to throw an error? I am with Paul on this. I would prefer an error. In the code you described below might not need an error, but the runtime logic the developer wants is wrong anyway. As a developer, I want the error thrown so I don't have to track down the obscure behavior from a runtime error. Maybe the solution is to add a catch errors property/attribute to either dabo or dApp that will catch or not catch errors. That way people can develop like they prefer. > > self.DisplayLocked = False > ...code... > self.DisplayLocked = False > > This is doing exactly the same thing as calling > unlockDisplay() twice without ever calling lockDisplay(). IOW, this is > an artifact of the implementation, and is not a logic error. > > -- 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-users Searchable Archives: http://leafe.com/archives/search/dabo-users This message: http://leafe.com/archives/byMID/dabo-users/!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAafA2fnYuPUOMNFpIYnBEQcKAAAAQAAAAZf/[EMAIL PROTECTED]
