I find that any number of clicks on a locked field consistently
recognizes the field as the target, but unfortunately the rest of the
description provided is too complex for me to be able to understand how
to reproduce what you're seeing.
Do you have a simple example stack in which you can demonstrate this?
It may be that in the course of simplifying your setup to produce this
simple example stack you may find the source of the issue. Happens to
me all the time. :)
If not, at least you'll have a good example others can use to verify the
issue, and it'll be necessary if a bug report is filed.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
David Epstein wrote:
I have encountered a bizarre problem that occurs in a somewhat complicated
context. I wonder if anyone has experienced anything similar.
In short: when I click a locked field on one occasion “the long id of the
target” returns the expected result; but when I click on it subsequently “the
long id of the target” returns the long id of the card instead.
Details:
To allow the user to edit certain properties of a card, I copy a “dropPanel”
group to that card, allowing the user the adjust various controls on that group
whose settings I use to adjust the appropriate properties of the card. I want
the “dropPanel” to disappear if the user clicks outside of it, so I insert a
frontScript that, on mousedown, checks whether the targeted object is part of
the dropPanel group.
This has worked well for a long time, but I now encounter this problem.
Several of the controls in one of my dropPanels are locked fields (call one of
these “A”). The first time one is clicked on, it operates as expected. But on
subsequent clicks my dropPanel gets deleted. When I debug my frontScript, I
see that on the first occasion the long id of the target is recognized as
“field id x of group id y of… etc.”—and my script confirms that this control is
indeed part of the dropPanel group and so clicking it should not delete that
group. On subsequent clicks, however, that same target is interpreted as “card
id x… etc.”, which of course is not a member of the group, and this causes my
group to be deleted.
Why does my field “A” lose its identity between these two clicks? When working
properly, the click on the locked field causes a different group to be created
adjacent to it, allowing the user to select one or more things from a list
field (“B”), and then click a Cancel or OK button. (This subgroup does not
have the auto-close feature). The OK button of that subgroup sets a custom
property of and sets the text of field “A”—neither of which seems like it
should cause that main field no longer to be recognized as a target. And the
Cancel button does nothing at all to the main field. OK and Cancel both delete
the subgroup that includes them and Field “B”.
Testing various combinations of events, I learned that the problem arises
whenever the user selects something in the list field “B”—regardless of whether
he clicks OK or Cancel—but there is no problem if he never makes a selection in
that list field “B”—again, regardless of whether he clicks OK or Cancel. (And
if toggleHilites is true for field “B” the problem arises even if the user
removes a selection he initially made).
So it seems as if nothing my scripts do to Field “A” is associated with its
losing its identity; it is rather the fact that one or more lines have been
selected in a different field (the list field “B”). Two more symptoms
- clicking on a second locked field that operates in the same way also causes
the problem; i.e., two clicks on one field or one each on two fields makes no
difference.
- Field A does not seem to lose its identity until the subgroup containing
Field B is deleted. If a wayward user repeatedly clicks on Field A and makes a
selection in Field B without clicking OK or Cancel, the script as written will
keep creating new subgroups with new Field B’s. Only after the user has
repeatedly clicked OK or Cancel to remove the duplicative series of subgroups
will a click on Field A cause the problem.
Thanks very much for any insights about this.
David Epstein
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
