On Jun 19, 2007, at 2:34 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
> I found and read the coments on lockDisplay. Apparently the lock
> and unlock
> are a 1 to 1 relation, similar in functionality to the SQL Begin
> Trans/End
> Trans where the transactions is not actually "committed" (or in our
> case the
> display is actually not unfrozen) until the outermost call is
> completed and
> you cannot have more unlocks than locks.
Exactly - it's a push/pop approach. Imagine if a routine locked the
display, and then called another routine that also locked/unlocked
the display. If all it took was a single unlock to undo all the
previous locks, you would have to be very careful to preserve the
state. This way, as long as you clean up after yourself by making
sure you unlock any lock you set, things will be fine.
I've added some code to dPemMixin that will prevent exceptions like
you received from disrupting your program. Instead, the error is
logged and the program continues. And anticipating Paul's question
(<g>), yes, I think that this is preferable to the program crashing,
and too many unlocks are not fatal in nature, but should not be
ignored, either.
-- 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]
