finding & storing the field that *would* be next on closefield
dunbarx at aol.com
dunbarx at aol.com
Sun Oct 20 06:11:18 CEST 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.
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
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.
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
More information about the use-livecode