setProp/getProp and lock messages

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

setProp/getProp and lock messages

Post by monte » Wed Nov 20, 2013 1:58 am

@FourthWorld reminded me about the issue with getProp/setProp handlers and lock messages the other day so I thought I'd start a topic to discuss it. While I'm not really sure how much code would break if lock messages still sent get and setProps it does appear to have backwards compatibility issues on the surface. I suggested changing things on the handler end by declaring them somehow as required. I'm not positive on the syntax but I suggested:

Code: Select all

local sPropValue

virtual setProp uProp pValue
   put pValue into sPropValue
end uProp

virtual getProp uProp
   return sPropValue
end uProp
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: setProp/getProp and lock messages

Post by LCMark » Wed Nov 20, 2013 1:50 pm

I must confess this suggestion makes me somewhat uneasy. The definition of 'lockMessages' is pretty clear - if it is set to true, no messages are sent and thus no code at the script level (that you don't know about) executes. Given this unambiguous definition, it seems that introducing exceptions essentially renders lockMessages somewhat pointless - it becomes 'lock messages except if a handler decides it should always execute', which isn't really locking messages at all.

Also, making the definition on the handler itself causes issues in the behavior chain - what should happen if a getProp in a behavior always wants to be executed, but is 'overridden' in a derived behavior which doesn't always want to be execute (or vice-versa)?

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: setProp/getProp and lock messages

Post by FourthWorld » Wed Nov 20, 2013 4:00 pm

Thanks for introducing this topic here, Monte.

I agree with the simple consistency Mark advocates for lockMessages, but with custom prop triggers we have a special case that may require an inventive alternative.

With built-in props, behavior changes occur when a property is set regardless of the state of lockMessages. Setting the listBehavior of a field, for example, will change that field's behavior whether lockMessages is true or false.

Custom controls, however, often require custom properties, and unlike built-in properties for native objects the change can be suppressed if the user changes a property in a custom control while lockMessages is true. In some cases this may cause unexpected appearances, and in the worst case could conceivably result in data loss with some custom controls.

Also, once we have getProp and setProp for built-in properties, the same brittleness becomes introduced for overloaded built-in properties as well.

Because custom controls can be adversely affected by lockMessages, sadly I rarely use getProp and setProp, despite how good a fit they are for such things in all other respects, opting instead for accessor handlers to set those values and trigger those actions.

So to bring custom controls up to par with native controls in terms of robustness, some solution needs to be invented so they can be reliable and robust independent of whether the scripter needs to block system messages.

Unfortunately, at the moment I don't have a suggestion on how to solve this. I agree with Mark that the reliable consistency of lockMessages should probably not be compromised, yet I also believe there is a very real need for some means by which we can work with custom prop triggers without being affected by lockMessages.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: setProp/getProp and lock messages

Post by LCMark » Wed Nov 20, 2013 6:16 pm

Here's a thought (which I'm sure is not a new one!) - the idea of lockMessages is to stop engine messages from being sent - there's a certain mechanism in the engine which all engine originated messages use and that will do nothing if lockMessages is true. The getProp / setProp messages use the same mechanism but *technically* the message does not originate from the engine - it originates from script.

At the moment there are the following ways 'messages' get dispatched:
  • direct call (e.g. doMyHandler tParam1 in script).
  • send / call / dispatch
  • getProp / setProp handlers (invoked via 'the prop of obj')
  • engine events (e.g. mouseUp / mouseDown)
Of these only the last two no-op if lockMessages is set. Given that send/call/dispatch/direct calls which all originate from script ignore lock messages, perhaps getprop / setprop handler invocation should too?

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.

The argument for setProp/getProp messages not being considered to be engine messages is pretty simple - the only way they are ever invoked is by an explicit line in script:

Code: Select all

get the myCustomProp of <object>
And it is hard to see why that should be treated differently from:

Code: Select all

dispatch function "getMyCustomProp" to <object>
Of course, there *might* be backwards compatibility concerns with changing this - however, I suspect that's then a case of analysing what the use-cases for lockMessages actually are. (One argument, you can stop script from sending messages by not invoking the line that sends the message - the only way to stop the engine originating messages is to use lockMessages).

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: setProp/getProp and lock messages

Post by FourthWorld » Wed Nov 20, 2013 8:01 pm

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.
I think your reasoning is sound, and AFAIK would have no adverse effects on my scripts (only positive ones).

Still, it may be useful to raise the issue on the use-livecode list, with two benefits in doing so:
1. We may be able to turn up cases we're overlooking in which this may be problematic
2. No one could later complain that it was changed without notice. :)

Shall I make that post to the list?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: setProp/getProp and lock messages

Post by monte » Wed Nov 20, 2013 8:23 pm

I think this is a better solution I was only concerned about backwards compatibility. The good news is that it's not hard to avoid the handlers by getting/setting the whole custom property set.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: setProp/getProp and lock messages

Post by LCMark » Sat Nov 23, 2013 12:41 pm

@FourthWorld: If you could post to the list and ask what people think and marshal the discussion somewhat that would be great.

I'm always concerned about backwards-compatibility, but sometimes it is important to stop and look at something and really ask how it is used. In this case, if the only useful use-case for 'lockMessages' is to stop events being dispatched (i.e. mouseUp etc.) then it could be that the setProp/getProp thing was a side-effect of implementation rather than an intended result. Of course, it is always possible to argue either way, but in this case it seems to me that if there is no great aversion to changing the behavior slightly then the benefits are great.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: setProp/getProp and lock messages

Post by FourthWorld » Sat Nov 23, 2013 4:41 pm

runrevmark wrote:@FourthWorld: If you could post to the list and ask what people think and marshal the discussion somewhat that would be great.
Done. I'll monitor replies and summarize any useful info here.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: setProp/getProp and lock messages

Post by LCMark » Sat Nov 23, 2013 6:39 pm

I chatted to Kevin about this today to see if he knew whether there was a he remembered a specific reason underlying the current situation with lockMessages affecting setProp and getProp - it seems that it is very much a case of 'it has just always been that way'.

He came up with a couple of use-cases that he has used - the main thrust seemed to be efficiency, i.e. to stop lots of messages when setting many such properties at once (i.e. bypassing whatever the setProp/getProp handler does and fetching/setting the value direct). However, he agreed that using it for that was more because it could be done like that and was quicker (albeit dirtier) than providing an extra mechanism in the 'custom control' for such a purpose. I think the thrust was that had lockMessages never affected setProp/getProp then it wouldn't have caused a problem, it would have just required a slightly different scripting approach for those cases.

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 7215
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: setProp/getProp and lock messages

Post by jacque » Sat Nov 23, 2013 8:20 pm

I posted this to the list, but I think it may be the primary reason that lockMessages affects setProp. This is 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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: setProp/getProp and lock messages

Post by FourthWorld » Sat Nov 23, 2013 8:53 pm

I had hoped to continue the discussion in the public list and provide summaries here once more people have had a chance to chime in, but your point is a good one and here's the reply I posted about it to the list:


Good point, Jacque - thanks for bringing that up.

Since it involves what is really an erroneous circumstance, it would
seem only as serious (and far less frequently encountered) than what
happens when you put an answer dialog in a loop and can only escape by
quitting.

Maybe the solution for that isn't to continue hampering the usefulness
of getProp/setProp, but something that would address all the many such
issues we encounter with recursive errors at runtime.

One thought that comes to mind might be to somply have Cmd-. work. :)

Right now that doesn't truly exit to top in all cases, and has no effect
with dialogs, which are especially problematic since they have their own
event loops.

Maybe the dev engine could be enhanced so that as long as the
environment is "development", Cmd-. exits dialogs and any loops and any
recursive stuff and truly brings a complete halt to all execution.

Whether or not this should be extended to include runtime is a more
complex issue, but if Cmd-. worked in LC as it did in HC it would have
saved me many, many hours over the years.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

LCMark
Livecode Staff Member
Livecode Staff Member
Posts: 1206
Joined: Thu Apr 11, 2013 11:27 am

Re: setProp/getProp and lock messages

Post by LCMark » Sat Nov 23, 2013 9:33 pm

Hmmm - at first sight this is certainly a concerning aspect... However, the same is true of this:

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
Indeed, as far as I can see, the two are equivalent in the (syntactic sugar) sense that you could notionally rewrite every instance of (assuming you could 'dispatch' setprops):

Code: Select all

set the myCustomProperty of <object> to <value>
as (note dispatch setprop does not exist as syntax - this is pseudo-LiveCode):

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
The point here is that the message path means recursion is easy to make happen if an object passes (or doesn't handle) a message. In the myRecursiveHandler case you cannot use lock messages to handle it, the code is wrong - should the setprop case be any different?

Clearly the intent of such code would be to handle the setting of the actual custom property value (i.e. the one stored in the custom properties of the value) at the card level rather than the object level (i.e. what would happen if the erroneous setProp handler was actually in the button itself, not the card) to a different value from what has been requested (if it wanted the same value, it could just pass). However, this is masking the fact that the engine is actually doing something special in the case of a setProp handler triggering at the button level - i.e. it will not send another message which is another exception to message passing rules. That rule is equivalent to not allowing a recursive invocation of a handler from within the handler which would mean bye-bye recursive functions.

The use-case this example is highlighting is actually significant and not erroneous - it is the ability to get/set the object's stored custom property value from within the invocation of a setProp/getProp handler at any level in the message path. 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.

Now, setProp/getProp handlers are special - you can only invoke them via property syntax so perhaps they do need to be special-cased in terms of recursive invocation. The engine could be changed to make the recursion not happen - i.e. extend the special-case when a object's setprop calls itself to any handler that calls the object's setprop if the object's setprop is on the stack. However, to my mind (at the moment at least) there still seems something slightly underhand and dirty going on here...

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: setProp/getProp and lock messages

Post by monte » Sat Nov 23, 2013 9:55 pm

However, to my mind (at the moment at least) there still seems something slightly underhand and dirty going on here...
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...

As for Cmd+. it would be great if this would topLevel all open modals... perhaps with the exception of ask and answer.

Either way if the IDE ignored errors if it already had the debugger open for that object and when not in debug mode had a way to change the error dialog from modal to palette then then we could fix resizeStack errors without quitting. I wonder if errors could be ignored after they are first presented for the session until the script is re-applied... if only we could contribute to the IDE.
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.
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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 9802
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: setProp/getProp and lock messages

Post by FourthWorld » Sat Nov 23, 2013 11:50 pm

I must admit I'm having a tough time understanding Mark's last post.

A few of the messages in LiveCode come with unique limitations (like mouseWithin only being sent to the control and only if there's a handler for it, or similarly with idle), so if getProp and setProp have speciall considerations I'm okay with that. Those issues are the same whether they're made useless with lockMessages or not, so why not increase their usefulness with making them immune to lockMessages and deal with any other issues with them later on?

Maybe I just need more coffee.

On the separate matter of a universal way to exit the many circumstances that can lock up the IDE:
monte wrote:As for Cmd+. it would be great if this would topLevel all open modals... perhaps with the exception of ask and answer.
Answer is the #1 reason some form of escape is needed.
I wonder if errors could be ignored after they are first presented for the session until the script is re-applied...
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.
if only we could contribute to the IDE.
::sigh::
Seven months in and LiveCode is only half open source.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1564
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: setProp/getProp and lock messages

Post by monte » Sun Nov 24, 2013 12:13 am

FourthWorld wrote:Answer is the #1 reason some form of escape is needed.
Yes... sorry I meant that ask and answer dialogs would just close but custom modals would toplevel.
FourthWorld wrote:It kills me when I make a mistake in a resizeStack handler in LC.
Indeed it's painful and causes data loss if you didn't save before you are forced to quit...
FourthWorld wrote:Seven months in and LiveCode is only half open source.
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.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

Locked

Return to “Engine Contributors”