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
