Code: Select all
local sPropValue
virtual setProp uProp pValue
put pValue into sPropValue
end uProp
virtual getProp uProp
return sPropValue
end uProp
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Code: Select all
local sPropValue
virtual setProp uProp pValue
put pValue into sPropValue
end uProp
virtual getProp uProp
return sPropValue
end uProp
Code: Select all
get the myCustomProp of <object>
Code: Select all
dispatch function "getMyCustomProp" to <object>
I think your reasoning is sound, and AFAIK would have no adverse effects on my scripts (only positive ones).runrevmark wrote:My concerns outlined above were about introducing exceptions to lockMessages - however, if it can be agreed that setProp/getProp handlers are in fact *not* engine messages (and are more like send / call / dispatch / direct calls) then they should ignore the setting of lockMessages thus solving the issue without any need to introduce new types of handlers, or special cases.
Done. I'll monitor replies and summarize any useful info here.runrevmark wrote:@FourthWorld: If you could post to the list and ask what people think and marshal the discussion somewhat that would be great.
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.
Code: Select all
-- in button script
on mouseUp
myRecursiveHandler
end mouseUp
on myRecursiveHandler
pass myRecursiveHandler
end myRecursiveHandler
-- in card script
on myRecursiveHandler
dispatch "myRecursiveHandler" to the target
end myRecursiveHandler
Code: Select all
set the myCustomProperty of <object> to <value>
Code: Select all
dispatch setprop "myCustomProperty" to <object> with <value>
if it is "not handled" then
lock messages -- you can only do this because of the exception
set the myCustomProperty of <object> to <value>
unlock messages
end if
Are you saying it's dirty and underhanded to ensure the recursion doesn't occur? I guess it might be possible for someone to rely on the recursion in some way...However, to my mind (at the moment at least) there still seems something slightly underhand and dirty going on here...
You can safely do this by getting and setting the whole set and also by passing. So the only use cases for actually using set again is if you modified the value or require it to be set on the object for subsequent use later in your setProp handler. The first case might be neatly handled by being able to pass modified parameters. The second case would seem easy to script around but both cases are handled by blocking recursion.The fact that the above is the only way to (safely) do this at a higher level in the message path of the object does mean this behavior is most likely relied upon in existing scripts.
Answer is the #1 reason some form of escape is needed.monte wrote:As for Cmd+. it would be great if this would topLevel all open modals... perhaps with the exception of ask and answer.
Yes oh yes please! MC was MUCH more graceful about handling accrued errors like resizeStack. It kills me when I make a mistake in a resizeStack handler in LC.I wonder if errors could be ignored after they are first presented for the session until the script is re-applied...
::sigh::if only we could contribute to the IDE.
Yes... sorry I meant that ask and answer dialogs would just close but custom modals would toplevel.FourthWorld wrote:Answer is the #1 reason some form of escape is needed.
Indeed it's painful and causes data loss if you didn't save before you are forced to quit...FourthWorld wrote:It kills me when I make a mistake in a resizeStack handler in LC.
To be fair open source projects aren't required to accept contributions. I myself advised Ben not to bother until the real problem is resolved. It's just too much of a headache for them unless they can very easily see the changes being contributed. I'm not sure if the reality escapes RunRev that we could have a much better IDE with just one (probably part time) resource acting largely as an integration/project manager coupled with community contributions and the tweaks the rest of the RunRev team makes for bugfixes, engine and environment changes.FourthWorld wrote:Seven months in and LiveCode is only half open source.