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

dunbarx at dunbarx at
Sun Oct 20 00:11:18 EDT 2013


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.



-----Original Message-----
From: Dr. Hawkins <dochawk at>
To: How to use LiveCode <use-livecode at>
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> 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

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

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

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
Please visit this url to subscribe, unsubscribe and manage your subscription 


More information about the Use-livecode mailing list