finding & storing the field that *would* be next on closefield

[dunbarx at aol.com]

Hi.


Still not sure what the "would be..." is. There isn't any mind reading required, is there?


But could you set a flag, maybe in a custom property, on closing the field in question, and then when any other field takes focus, check that property? If the newly focussed field is the one you are interested in, clear the flag, if not keep it.


I just wrote that last, and see that it might have value in some way, but now am not sure it addresses your problem at all.


Hmmm.


Craig




-----Original Message-----
From: Dr. Hawkins <dochawk at gmail.com>
To: How to use LiveCode <use-livecode at lists.runrev.com>
Sent: Sat, Oct 19, 2013 9:29 pm
Subject: Re: finding & storing the field that *would* be next on closefield


On Sat, Oct 19, 2013 at 2:48 PM, <dunbarx at aol.com> wrote:

> "would have gone..."
>
>
> Do you mean the next field in tab order?
>

That's what makes it difficult:  tab order is easy (and Jacque's suggestion
takes what I've already done with the groups a step farther, and makes
sense).

But the "next" field could be one that got clicked it (use
mouseControl()?), or the use of an (anehanced) arrow key from the row above
it.

I would not ever design a stack where an object containing a running
> handler might be deleted, just on principle.
> Can't you move that process to a handler in the stack, using "send in
> time" if you want it delayed, as you said?
>

It already happens that way--you *can't* delete an object whose handler is
still running, even if it's just waiting for something it called to come
back.

But If I'm not sure of the order in which things will execute . . .


-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462
_______________________________________________
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode