behavior object properties set prop/get prop
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark
Re: behavior object properties set prop/get prop
right... I don't think we will be ready for that stuff until the engine can load custom control and render them on the fly just like it does with the regular controls. So you would have a scrollbar and you could set it's style to round and it would load the custom control that is registered as a round scrollbar...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: behavior object properties set prop/get prop
First of all, like my comments on 'the properties' thread it is very important to separate what the engine should allow developers to do and what information the IDE needs to be able to allow effective editing. At the moment, there is no way to get the 'meta-information' the IDE needs to do its job so it is hard-coded (in the IDE); if we implement what is discussed here it doesn't change anything in that regard, nor will it. The solution to the meta-information problem has nothing to do with setprop/getprop handlers - custom controls (and engine controls) need to be able to describe to the IDE what properties they have, what those properties can be set to, and any other information that that side of things might need but I think that is a completely separate discussion to have.
So, back to the original focus of the thread - should getprop/setprop handlers be allowed in full generality - i.e. allowed for engine property names as well as non-engine property names.
The reason this was not done in MetaCard (and now LiveCode) was for performance (dispatching a message on every property set / get rather than just custom ones) - however, from what I can see we have a strategy that almost completely mitigates this issue: we restrict the check for whether the message needs to be sent to whether the object or its behavior (or behavior chain, when we enable chained behaviors) contains a handler for the property.
Now, the only dragon(s) I see lurking here are what to do about the places in the engine that use recursive calls to getprop() / setprop() - e.g. to fetch name / id properties when listing things, or to work out the effective values of things like colors and textSize. I certainly think the name / id / layer properties need to be reserved and not overridable (otherwise think of the mess that could result), but I'm not so clear on the inherited ones. Part of me thinks that once the functionality has hit the engine it should remain in the engine (and not call out to script) but I can't think of a suitable use-case to appropriate analyse at the moment...
Any thoughts?
So, back to the original focus of the thread - should getprop/setprop handlers be allowed in full generality - i.e. allowed for engine property names as well as non-engine property names.
The reason this was not done in MetaCard (and now LiveCode) was for performance (dispatching a message on every property set / get rather than just custom ones) - however, from what I can see we have a strategy that almost completely mitigates this issue: we restrict the check for whether the message needs to be sent to whether the object or its behavior (or behavior chain, when we enable chained behaviors) contains a handler for the property.
Now, the only dragon(s) I see lurking here are what to do about the places in the engine that use recursive calls to getprop() / setprop() - e.g. to fetch name / id properties when listing things, or to work out the effective values of things like colors and textSize. I certainly think the name / id / layer properties need to be reserved and not overridable (otherwise think of the mess that could result), but I'm not so clear on the inherited ones. Part of me thinks that once the functionality has hit the engine it should remain in the engine (and not call out to script) but I can't think of a suitable use-case to appropriate analyse at the moment...
Any thoughts?
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: behavior object properties set prop/get prop
@runrevmark - are you referring to overriding "the effective" whatever? I can't think of a case when that would be a good idea. And I can think of several where it wouldn't.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: behavior object properties set prop/get prop
Hmm... I've got no problem dropping the name, id, layer.. good plan. I'm not sure how I will know if the call is recursing up the object hierarchy for effective though... In general I think if someone has gone to the trouble to script a handler to return something slightly different for a property then it should be included in the effective version too... otherwise even with a property set the effective will return something different to the property...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: behavior object properties set prop/get prop
Ah. Yes, I was thinking of a local override, where the user requests "the effective". In that case you've got
should return the inherited blah property, not the locally overridden one, whether or not a getProp handler exists in the behavior object.
should return the local getProp version.
but
should return the overridden blah property, rather than the built-in one.
Code: Select all
currentObject:
getProp blah
-> behaviorObject
getProp blah
Code: Select all
get the effective blah of control "CurrentObject"
Code: Select all
get the blah of control "CurrentObject"
but
Code: Select all
currentObject:
-> behaviorObject
getProp blah
Code: Select all
get the effective blah of control "CurrentObject"
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: behavior object properties set prop/get prop
Hmm... that would be at odds with the rest of the inheritance path
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: behavior object properties set prop/get prop
Rethinking after being properly caffeinated..
Yes, I stand corrected. "The effective" whatever should return the overridden value anywhere along the chain. If there's not override then the end of the chain will provide the value.
Never mind.
Yes, I stand corrected. "The effective" whatever should return the overridden value anywhere along the chain. If there's not override then the end of the chain will provide the value.
Never mind.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: behavior object properties set prop/get prop
This would require a change to the uses of 'getprop()' in the engine - it's not a big thing to change and can be perhaps something we can evaluate when its in a version for release.Hmm... I've got no problem dropping the name, id, layer.. good plan. I'm not sure how I will know if the call is recursing up the object hierarchy for effective though... In general I think if someone has gone to the trouble to script a handler to return something slightly different for a property then it should be included in the effective version too... otherwise even with a property set the effective will return something different to the property...
Of course, another example is that of 'the properties' property which uses 'getprop()'... Should this return the overridden values (for controls that override engine properties), or should it return the internal ones? [ I guess using 'lock messages' around the usage of it solves any problem that might arise though ... ]
Re: behavior object properties set prop/get prop
Hmm... what's the getprop change. It all seems to work fine as is.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: behavior object properties set prop/get prop
I meant if it turned out it was a bad idea for 'effective' and 'the properties' to be hung off of overridden getProp handlers (e.g. when you get the effective foreColor, the engine calls getprop() on the parent) then it would require a change to the sites that use getprop() in the engine.
Re: behavior object properties set prop/get prop
Ah.. well I think your lockMessages plan is the way to go there... is there anything I need to do to enable that?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: behavior object properties set prop/get prop
Well, nothing explicit as it would be in script... e.g.Ah.. well I think your lockMessages plan is the way to go there... is there anything I need to do to enable that?
Code: Select all
lock messages
get the properties
unlock messages
Re: behavior object properties set prop/get prop
@Monte : if you send a pull-request for the work you've done on this already, I'll take a look and see what's left to do... I think we do have to be wary of performance so minimising the scope of the messages (i.e. only try and send them if they are present in target object / behaviors) and minimising string comparisons is quite important. Neither of these things should be too difficult though - I'm more than happy to help to get this to a point we can integrate into develop
Re: behavior object properties set prop/get prop
Lol... thought I'd already sent it... done
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: behavior object properties set prop/get prop
Just wondering what the status of this is?
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/