behavior object properties set prop/get prop

[monte]

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...

[LCMark]

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?

[mwieder]

@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.

[monte]

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...

[mwieder]

Ah. Yes, I was thinking of a local override, where the user requests "the effective". In that case you've got

Code: Select all

currentObject:
  getProp blah
  -> behaviorObject
        getProp blah

Code: Select all

get the effective blah of control "CurrentObject"

should return the inherited blah property, not the locally overridden one, whether or not a getProp handler exists in the behavior object.

Code: Select all

get the blah of control "CurrentObject"

should return the local getProp version.

but

Code: Select all

currentObject:
  -> behaviorObject
        getProp blah

Code: Select all

get the effective blah of control "CurrentObject"

should return the overridden blah property, rather than the built-in one.

[monte]

Hmm... that would be at odds with the rest of the inheritance path

[mwieder]

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.

[LCMark]

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...

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.

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 ... ]

[monte]

Hmm... what's the getprop change. It all seems to work fine as is.

[LCMark]

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.

[monte]

Ah.. well I think your lockMessages plan is the way to go there... is there anything I need to do to enable that?

[LCMark]

Ah.. well I think your lockMessages plan is the way to go there... is there anything I need to do to enable that?

Well, nothing explicit as it would be in script... e.g.

Code: Select all

lock messages
get the properties
unlock messages

As I said, this may be something that needs to be reviewed as I'm not 100% sure of the consequences of the engine not getting what it expects from getprop() in certain circumstances. But hey, we can try it and see

[LCMark]

@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

[monte]

Lol... thought I'd already sent it... done

[monte]

Just wondering what the status of this is?