On Mon, Jul 16, 2012 at 8:36 AM, Mark Wieder wrote:
> lock screen
> do some fiddling with screen objects
> unlock screen
> more code
>
> That way I can nest calls safely without having to worry about the
> lock state.
Once to this point, the only functions called should be recursions to
the value
Doc-
Sunday, July 15, 2012, 2:54:29 PM, you wrote:
> That raises the question, though--do I need to worry about ever "leaving"
> an extra lock lying around?
I always worry about that, so I try to lock down as little code as
possible at a time and make sure there's no other exit possibility:
loc
On 7/15/12 4:54 PM, Dr. Hawkins wrote:
That raises the question, though--do I need to worry about ever "leaving"
an extra lock lying around? It sounds like reaching an idle state will take
care of that for me.
Yup, it should.
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
Hy
On Sunday, July 15, 2012, J. Landman Gay wrote:
>
> I got lost in your description, but I don't think the above will be a
> problem. Locks are nested and the screen won't unlock until the last paired
> "unlock" executes, provided no idle events occur (all locks are cancelled
> on idle.) That means
On 7/15/12 4:00 PM, Dr. Hawkins wrote:
Anyway, the snake I see lurking in the grass is if the called card
needs to call another. Then it locks the screen again, unlocks it,
and, whoops!, the user sees cards popping around.
I got lost in your description, but I don't think the above will be a
I have cases where my defaults "cascade". It's one of the advantages
of what I'm doing over the competition.
It's easy to handle on a single card, or when the information is
inherited before the card loads, but now I want to make sure that I'm
not about to blow my foot off.
My cards load all of
