Feedback request: getProp/setProp and lockMessages

[Robert Mann]

Hi, I started using setProp & getProps and find it « elegant », worthwhile
encouraging.

I understand that
-- this is more and more useful for custom controls.
-- and that the current scope of the lockmsg command could (badly!)
interfere with that. 
Hence this proposal to restrict the scope of the lockmsg command to strictly
system msg.

As jacqueline points out : the lockMsg command is required in the set/get
prop context when a setProp handler sets the property of a child.

Using a parent setProp handler to set a child’s, or grand child’s etc..
property seems useful for all temporary objects dealt with. It does not seem
a good idea to kill that practice.

I personally like the idea of being able to move further in the path of
« object programming » with livecode, in the trail of the articles about
« oops in livecode » that were published a while ago.

So 

1) I definitely thing and *vote massively for the cmd « something » action
to really work to halt any process* launched in the IDE. It’s hard to
conceive that this does not yet work!!! This has cost to all of us some lost
NRJ.

2) I do vote *in favor of this proposal to exclude set prop & getProp msg
from the scope of the lockMsg* command, to favor the development of custom
controls.

3) I propose to either 

---- *b) add a parameter to the set & get prop msg*, to deal with the
situation when one set/get a child’s property. Something like :

set the myCustomProperty of the target to newValue *with lockMsg*
(with lockMsg being optional)

or 

---- b) *modify the msg path behavior* so that a script launched by a
parentObject sends as usual a msg up the path, but that this msg does not
come back up. A kind of « one shot » short live msg « shouted » back down
the path for kids!

To my view this would simplify the use of livecode and contribute to
*liberating a little the « oops » potential of live code*.

it's kind of brain tease to have to cope with the systematic msg path and
the whole point of the lockmsg was to bring a little peace in mind... 

/What can be seen as a restriction would in fact be an addition to the
language : like a downward msg path that will be opened up./

or

----- c) solution a) extended to all commands :: all commands could have
have an *optional parameter like "scope"* or "mode" to trigger  a kind of
*msg path scope*, but only for that precise command.

example : set the myCustomProperty of the target to newValue *scope local*
scope could have the standard default value "up" (msg send up the path)
or "local" (msg not sent) or "down" (msg sent down the path) or UpandDown
(up and down the path..)

To start with  the two values "up" and "local" could be implemented for a
start, and that could be extended later to cope with downward msgs.

I would love that third (c) option if feasable!

Robert man






--
View this message in context: http://runtime-revolution.278305.n4.nabble.com/Feedback-request-getProp-setProp-and-lockMessages-tp4672821p4672920.html
Sent from the Revolution - User mailing list archive at Nabble.com.