LiveCode Forums.

I think being able to use SetProp and GetProp handlers on both global properties such as DefaultFolder and stack properties such as Name and Label would be a benefit as one would be able to use one to stop someone changing the DefaultFolder to something else and possibly breaking the application if they use relative paths such as ..\Configuration and so on.

It could be a potentionally good idea.

Limiting getProp and setProp to custom properties was done to keep the message path lean. The more options that are present for messages, the more it impairs overall performance.

You can see the difference by benchmarking custom property settings with and without setProp handlers, and then imagine what would happen if that were implemented for all properties.

That said, many (including myself) believe the value of using getProp/setProp for built-in properties outweighs the performance hit, and may be able to be implemented with other optimizations that minimize that hit.

You can add your votes for that at the RQCC:
http://quality.runrev.com/qacenter/show_bug.cgi?id=3126

In the meantime, one way to work around this is to virtualize built-in properties. For example, if you need to take some action whenever the text in a field is set by script, instead of setting the text property you could make a setProp uText handler to do what you need.

Not as graceful nor as universally applicable as using setProp for native props, but hopefully will spark ideas for ways you can use whats' available now to complete the task at hand.

I didn't realise there was an actual performance hit, although surely on a high end machine such a penalty would be hardly noticable wouldnt it?

Unfortunately, the performance hit *is* noticeable, with the effect dependent on the complexity of your code. However, I do believe that the lack of being able to override the builtin properties is an enormous barrier to true object orientation. For instance, I've got a knob control which really should subclass from the scrollbar object. But since I can't simply make it a scrollbar control with a different visual aspect, I can't set or get the thumbposition of my knob control - not being a scrollbar, it doesn't have (and can't have) a thumbposition. I'd gladly take a performance hit here rather than have to tell users to set the uThumbposition of the control.