Feedback request: getProp/setProp and lockMessages

[J. Landman Gay]

On 11/23/13 11:14 AM, Mark Wieder wrote:

> I cautiously think this is a Good Thing. My hesitation is that
> lockMessages is critically important in being able to rescue stacks
> that have been set into infinite loops in resize and preopenstack
> handlers, etc. I realize that this change won't affect those because
> they're system messages and so would be masked, but I keep thinking
> that *somehow* there's a way to get into trouble. But since I can't
> come up with a problem situation right now, I'll give this one thumb
> up and cross the other one behind my back. Ouch.
>

That was the first thing I thought of when I read Richard's proposal. 
 From the dictionary:

***
Caution! If a setProp handler in one object's script sets the custom 
property for a different object, and the first object is in the second 
object's message path, a runaway recursion will result. For example, if 
the following handler is in a card script, and you set the 
"myCustomProperty" of a button on the card, runaway recursion will result:

   setProp myCustomProperty newValue
set the myCustomProperty of the target to newValue + 1
-- Because the target is the button, and this handler is in
-- the card, the above statement sends another setProp trigger
-- to the button.
   end myCustomProperty

To avoid this problem, set the lockMessages property to true before 
setting the custom property.
***

So we'd either need a special kind of lock just for setprop, which seems 
convoluted to me, or some other solution. Or a huge 60-point warning in 
red text all over the documentation.

-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com