behavior object properties set prop/get prop

[LCMark]

What's being discussed above covers this case too

[mwieder]

Cool. Just wanted to make sure. It's kind of the opposite case of what was discussed, and I'd love to have this in place soon.

[monte]

Right... hmm.. looks like there's no parse error throwing on setprop/getprop anyway...

Code: Select all

if (type != ST_ID ||
			sp.lookup(SP_COMMAND, te) != PS_NO_MATCH ||
			(sp.lookup(SP_FACTOR, te) != PS_NO_MATCH &&
			te -> type == TT_FUNCTION))
	{
		MCperror->add(PE_HANDLER_BADNAME, sp);
		return PS_ERROR;
	}

It's just never executed because the MCObject set prop/get prop etc doesn't implement it.

[mwieder]

...try setting the thumbposition of a button. There's *something* throwing a parse error...

[monte]

ah... ok, I was talking about the setprop/getprop handler existence in the script. Hmm... yeah I see what you mean... the property parser in the different objects might need to default to checking if there's an implemented setprop handler in the object or it's behavior before throwing an error... see.. objectprops.cpp MCObject:setprop

[monte]

playing with this last night... pretty cool... I've got it roughly working for set prop but only in properties that MCObject handles... will need to move the code into a method of MCObject and then call the method from the setprop method of each concrete object type. @mwieder I tested and you can override engine properties in the wrong object (I tested thumbposition of button but if you pass it still throws the error which is cool and what I would expect...

[monte]

ok, tweaked my code so you can setprop any synonym too...

[mwieder]

Throwing an error if you pass seems like the right behavior. As long as there's nothing else to catch the message: for instance, set the thumbposition of a button, then pass the message so that the button's group can also do something with it. I could live with that.

Throwing an error if you override an existing property and then pass wouldn't be as cool. Might want to do something to extend the existing behavior beyond just setting the property, and then hand off setting the property itself to the engine.

[monte]

Exactly... if you pass to the engine and the engine can't handle it then there's an error... if you pass and the engine can handle it then it just does what it normally does. It's exactly like passing a custom property setProp. Also, just the same as with custom properties if you explicitly set in the handler then it won't recursively run the setProp handler again... I've just implemented getProp... I'll commit and push it up so you can pull it from my repo if you want to play

[monte]

https://github.com/montegoulding/liveco ... op_setprop

[phaworth]

Throwing an error if you pass seems like the right behavior. As long as there's nothing else to catch the message: for instance, set the thumbposition of a button, then pass the message so that the button's group can also do something with it. I could live with that.

Throwing an error if you override an existing property and then pass wouldn't be as cool. Might want to do something to extend the existing behavior beyond just setting the property, and then hand off setting the property itself to the engine.

OK, I'm not sure I fully understand this but is the gist that you will be able to set a property of an object even though that object doesn't have that property? If so, I'm not sure I like that, too many opportunities to shoot yourself in the foot. Isn't that what custom properties are for?

Pete

[mwieder]

Thanks. I take it you haven't pushed yet - the latest update seems to be 19 hours ago. I feel like Jacque's timewarp has grabbed hold of me.

[mwieder]

Pete - there are cases where you *can't* set a custom property. As in my example, try setting the thumbposition of a button. It doesn't exist as a built-in property of a button and you can't set it as a custom property. You have to come up with a new naming convention.

[monte]

Basically this will allow us to create custom controls that have the same properties as engine controls.

GitHub seems to be asleep... the branch isn't showing up but it's definitely there... some pages seem to know about it but others don't... maybe there's a cron job or something that updates some of the pages...

Anyway.. here's the commit: https://github.com/montegoulding/liveco ... aa6312b909

[mwieder]

Thanks. Pulled. Wow - that's a lot of similar-looking changes.