LiveCode Forums.

It would be wonderful if existing objects (button, fields and so on) could have their capabilities extended by allowing end users to
add additional properties to them.

This ability (to add extra properties to objects) should, preferably, be possible from within Livecode rather
than having recourse to another programming language such as C++.

I do wonder if there is also not a need for a new property inspector where ALL the properties
of an object are visible.

After all, if one looks up 'Button' in the dictionary there is no list of all
of a button's properties. This is a lack of transparency; and transparency
is a feature of most Open Source projects.

That is NOT an advance.

This is rather useless as I cannot work out how to get a list of an object's properties alongside the names of those properties:

And while the above may be extended to list all an object's props, and even adjust them; what it does not
do is allow one to add extra properties.

What tripped off this idea was an attempt to set the htmlText of a label;
which is not possible as a label does not have that property.

Now at that point the obvious reason to why a label does not have that
property is that whoever put together LABELs in Metacard or
Livecode either didn't think that would be a useful property, or it
didn't even cross their mind.

Expecting the designers of Livecode to think about all eventual uses and requirements
is asking way too much!

Therefore, were objects hackable in such a way that their properties could be extended
when end users found that they had a requirement for a property that did not exist in an object
as it came in Livecode, that would be a great service, AND . . .

there could also be a way where, once an end user has added a property to an object it could
be submitted back to RunRev for consideration as to whether that should become a regular
property of that object in the next version of Livecode.

Thanks to Bernd Niggemann!

Not documented at all.

See customKeys, getProp, and setProp.

richmond62 wrote:And while the above may be extended to list all an object's props, and even adjust them; what it does not
do is allow one to add extra properties.

As mentioned, getProp and setProp allows you to create your own virtual properties, as long as they don't require non-existent engine behavior. But the only way to change the engine itself is to revise the C++ code that drives it. How else could you add something like an html property to a label, when the engine itself must draw that label? When you are dealing with LC primitives, you have to change the engine code.

RR has provided a way to do that, but you must use the language that the engine understands. How else could it be possible?

"RR has provided a way to do that"

Well, that's a start.

However, if the engine understands C++
and not Livecode, there must be an interpreter
somewhere in between the engine and Livecode . . . ?

I would be very grateful if you could post where
RR has provided that way.

I probably wasn't clear. There are two ways to enhance the language. The first is to create your own virtual properties using setProp/getProp. Those of course can only use syntax that is already defined in the engine; that is, the syntax you find in the dictionary. These virtual properties apply only to your own stacks or apps; they are part of your scripts.

The second way is to actually change the engine we know as LiveCode. These new properties would alter the engine behavior for everyone, they become part of the LC build. If you want to add properties to native objects (the ones I called primitives, the objects in the tools palette) then you have to write engine code, and that has to be in C++. That's what the RR team and the open source contributors do.

There is no "interpreter" per se, the engine runs the code it is written in, and your scripts call the code that has been defined in the engine.

Virtual properties are pretty cool. You can define anything as a "property" by using a setProp handler. If you do not pass the setProp message, no actual custom property is assigned to the object, but you can define the behavior to act as though it were a built-in one. If someone else doesn't provide an example first, I'll try to do it tomorrow; it's late here right now.

I am aware that that involves C++.

Does that mean one has to work on the source from the Git Hub?

I'm not following. If getProp and setProp work, then why add it to the engine?

richmond62 wrote:Does that mean one has to work on the source from the Git Hub?

Yes, generally, though it isn't strictly required I don't think. You could download the source code and not resubmit to GitHub. I'm not sure if that's considered ethical since we're supposed to give back to the community, but you could do it.

I found an example of a virtual property in one of my stacks. This is a simple version of an on/off switch button that also changes an associated label field:
Now when I want to change the appearance on a button, I can say:

set the switchIcon of btn 2 to true

You can use getProp similarly, which allows syntax like the built-in functions; you can say "the something" instead of "something()".