behavior object properties set prop/get prop

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, LCMark

mwieder
VIP Livecode Opensource Backer
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

Post by mwieder » Sun Apr 21, 2013 6:28 pm

I see the revbuild.h.in file and nothing jumps out at me as being overtly weird. I'm probably unlikely to have time to look into this any more today, but I'll give it a try on my 32-bit system tomorrow.

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

Re: behavior object properties set prop/get prop

Post by monte » Sun Apr 21, 2013 9:23 pm

on my system at least when I manually created revbuild.h it started throwing a heap of ld errors so there could be some headers missing too
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: behavior object properties set prop/get prop

Post by monte » Mon Apr 22, 2013 12:32 pm

looks like Ian merged in a change for this
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

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

Re: behavior object properties set prop/get prop

Post by monte » Mon Apr 22, 2013 12:38 pm

which I just tried and I'm still getting the issue
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

livecodeian
Posts: 10
Joined: Mon Apr 22, 2013 3:29 pm
Location: Edinburgh
Contact:

Re: behavior object properties set prop/get prop

Post by livecodeian » Mon Apr 22, 2013 4:58 pm

Hi Monte & Mark. I've merged another fix into the release-6.0.1 branch. That should sort out the revbuild header issue. Wasn't aware of what the issue was when I posted the first fix, so ended up fixing something else :)

Ian.
Ian Macphail, LiveCode Ltd.

mwieder
VIP Livecode Opensource Backer
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

Post by mwieder » Mon Apr 22, 2013 6:22 pm

Fixing something else is always in good taste. :)
Your latest commit fixed the revbuild.h issue for me on my 32-bit system. I'll check it out on the 64-bit build after a while (don't have access to it right now, but I had the same symptoms on both before your latest fix, so I'm not expecting any surprises).

Update 23 April 2013: no problems with the 64-bit build either.
Last edited by mwieder on Tue Apr 23, 2013 5:46 pm, edited 1 time in total.

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

Re: behavior object properties set prop/get prop

Post by monte » Mon Apr 22, 2013 9:40 pm

great! fixed for me
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: behavior object properties set prop/get prop

Post by phaworth » Wed Apr 24, 2013 12:01 am

mwieder wrote:@Pete - the point of my example in this thread is that I have a knob control that is for all other purposed a scrollbar, just turned into a circle. It would make perfect sense to set the thumbposition of the control group, but I can't because thumbposition is a property of *only* scrollbars. With this new change I should be able to set the thumbposition and have circular scrollbars without having to resort to the trickery of setting the "uThumbposition" or the "knobPosition" or something else. If it otherwise acts like a scrollbar, then I should be able to treat it as a scrollbar. I shouldn't have to remember, and I shouldn't have to make users of my custom control remember, that the proper syntax is "uThumbposition", not "thumbposition".

Otherwise it's like saying that triangles are the only shapes that can be red.
Wait, you mean triangles can be blue :-)

Seriously, here's a couple of my concerns.

First, LC is already bad at detecting errors when referring to custom properties since it assumes any custom property you refer to must be valid (unless you use Alex Tweedly's explicit Properties plugin). I might be misunderstanding this change, but it seems to increase the likelihood of errors because right now if I refer to a built-in property that doesn't apply to the target, I get an Apply error. But with the change if I inadvertently refer to the same property, I get no error and who knows what happens at run time (see the next issue). Maybe that could be overcome by not allowing this change if strict compile mode is on.

The other thing that concerns me, although it can no doubt be checked, is any assumptions in the rest of the code that only scrollbars can have a thumbpos so that when that code executes on, say, a field, havoc ensues.

Monte - maybe that answers your questions too?

Maybe the new custom control features that are in the works might be a more appropriate place for this type of change to be implemented?

mwieder
VIP Livecode Opensource Backer
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

Post by mwieder » Wed Apr 24, 2013 12:22 am

Pete-

You've got valid concerns, but let me see if I can allay them...

Yes, the engine doesn't catch typos in custom property names. I can't think of a way to avoid that - if I type

Code: Select all

set the versionNum of control x to 3.14
instead of

Code: Select all

set the versionNumber of control x to 3.14
does the engine have any way of knowing what I meant? Are they two different properties or did I make a mistake?

Whether or not we allow property name overriding, that situation is the same.

If we *do* allow overriding, then at runtime there's a small difference. If you say (sticking with my example)

Code: Select all

set the thumbposition of field x to 42
and there's no setProp handler for thumbposition, you get a runtime error. The difference is that there's no compile-time error, but it's still not havoc. [Update: hmmm... thinking this over, possibly a "thumbposition" custom property gets set on the control instead of a runtime error] But still no major problems.

On the other hand, if there *is* a setProp handler for it, that handler gets executed. Maybe you really want to implement a thumbposition property for a field. If you pass the thumbposition message at the end of the handler it gets passed along the message chain and may get caught by another setprop handler in a behavior script, or may reach the engine and cause a runtime error. If you don't pass it then the message has been handled and all is well.

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: behavior object properties set prop/get prop

Post by phaworth » Wed Apr 24, 2013 1:08 am

Mark -
OK, you allayed my concerns, thank you. I had not picked up that there had to be a setprop handler in order for thumbpos to be a valid property for anything other than a scrollbar.

As far as the lack of error checking on property names, I understand why it has to be that way, at least at the moment. I just wish there was a reasonable way to somehow define the custom properties of an object but I can't think of one!

Pete

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

Re: behavior object properties set prop/get prop

Post by monte » Wed Apr 24, 2013 1:15 am

if I refer to a built-in property that doesn't apply to the target, I get an Apply error
You get a execution error not a parsing error.
The other thing that concerns me, although it can no doubt be checked, is any assumptions in the rest of the code that only scrollbars can have a thumbpos so that when that code executes on, say, a field, havoc ensues.
I'm not sure what you're talking about here... The change doesn't actually do anything to the object other than allow the setprop/getprop handler to execute. In the case of a thumbposition of a button if you needed to store the property you wouldn't be able to pass the message because an execution error would occur. So you would need to store it in a different custom property or script local or just as the actual position of the thumb...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: behavior object properties set prop/get prop

Post by phaworth » Wed Apr 24, 2013 2:25 am

Monte,
See my previous reply to Mark.

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

Re: behavior object properties set prop/get prop

Post by monte » Wed Apr 24, 2013 2:45 am

Cool.. I think it's a neat feature. If you want to just do some extra stuff when an actually object property is set then you handle it and then pass. If you want to give some different object the name of a built in property of some other object then you handle it and don't pass.

My implementation works and it's fun to play with... anyone can pull it and play but I expect runrevmark will have a number of changes he want's made. Most significantly he may want to change it so the handlers are are executed using their property number rather than working out the name of the handler from the property number then executing. He also may only want to handle it at the control and behavior level (a bit like resizeControl) rather than through the whole message path including frontscripts which is how I've currently implemented it. Both of these would give better performance I think but I'll let him tell me where he wants it to go from here.
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

phaworth
Posts: 592
Joined: Thu Jun 11, 2009 9:51 pm

Re: behavior object properties set prop/get prop

Post by phaworth » Fri Apr 26, 2013 12:37 am

Mark/Monte
I'm sorry to keep questioning this but I still feel uneasy about this.

Using Mark's triangle analogy, it's clear that a triangle can have any color because changing it's color doesn't stop it being a triangle. But there are other properties of a triangle that you can't change and expect it to still be a triangle - you can't have a 4-sided triangle, neither can you have a triangle whose angles add up to anything other than 180. Then there's other properties that divide triangles into subgroups - isosceles, right, etc.

Applying the same analogy to LC controls, there are some properties that fall into the same category - an option menu has its style set to menu and its menuMode set to option. Any other settings and it's not an option menu any more.

If a user decides to set those properties on a field, for example, then he's presumably doing it for a reason and can take account of it in his scripts. But for crazy people like me who like to write IDE plugins that have no control over how people design their apps, it could possibly cause my code to identify a control as an option menu when it's really a field and do something illegal with it on that basis.

I'm hoping you can explain my misgivings away :-)

Pete

mwieder
VIP Livecode Opensource Backer
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

Post by mwieder » Fri Apr 26, 2013 12:45 am

I'm hoping you can explain my misgivings away :-)
Not really. The docs are written that way.
If you want to read a read-only property, nothing is preventing you from doing that. You just can't get that property by parsing "the properties".

Locked

Return to “Engine Contributors”