The dreaded customproperties

[oldummy]

I have been reading through several posts concerning customproperties.Apparently I am too thickheaded to understand them as they are written.
My problem is I still do not know what the differences are between custompropertysets,customproperties, and customkeys or how to handle them.
It seems I need an elementary school teacher to show me.
I now need to delete a (I hate to specify as I am not sure anymore) either a customproperty or a customkey.
I probably need colors instead of some of the terms used.
Yes,thickheaded.

[richmond62]

A CustomPropertySet is the group of custom properties that belong to an object.

A CustomKey is the name of a custom property.

So I can set a customProperty of an object just like this:
-

-
and I can set as many customProperties as I like:
-

-
And I can get a list of the NAMES of those customProperties very easily:
-

[richmond62]

Personally I don't think of custom properties as 'dreaded', I tend to think of them like earrings: one can have none, one, two, or a whole slew, with all sorts of useful things attached.
-

customProps.jpg (7.17 KiB) Viewed 14830 times

-
The good thing about custom properties = earrings (unlike standard properties = tattoos) is that one can attach them and remove them as one wants.

[Klaus]

You can see "custom properties" as variables, which are neither LOCAL nor GLOBAL but attached to one LC object.
The name is -> the customkey, and EVERY object in LC can have CPs.

A "custom property set" is like that, but it is in fact an array:

Code: Select all

...
set the cYourCustomPropertySetName["western_greeting"] of this cd to "Howdy Cowboy"
...
answer the cYourCustomPropertySetName["western_greeting"] of this cd
...

A custom property can contain anything, even binary files like PDF, images, sound files or even a stack!
So this is a great way to store things that the user should not see and "spit" them out when neccessary.

[dunbarx]

Just jump right in.

Ignore customPropertySets for now, and just make and use custom properties. They survive sessions just like native properties and are incredibly useful. For example, let's say you had thirty fields, and wanted to be able to set the backColor of "some" of them to "red" if you click on a button.

In one scenario, assume that only the fields on the right side of the card were the ones to change color. You might have a handler that examines every field and only sets the backColor to red if the left of that field is greater than the middle of the card. Here you are using native properties:

Code: Select all

repeat with y = 1 to the number of fields
  if the left of fld y > the width of this cd / 2 then set the backColor of fld y to "red"

In scenario 2, you have only certain fields among the thirty that you want to change, but they can be anywhere on the card. You set the "changeToRed" custom property of those particular fields to "true", and then in the handler you:

Code: Select all

repeat with y = 1 to the number of fields
  if the changeToRed of fld y = "true" then set the backColor of fld y to "red"

Later on you can make fancier custom property sets.

Craig

[oldummy]

I do thank all again. I used to be a lot more comfortable with custom properties, and have written stacks using them, (one of which I use almost daily), I really do like to use them. I don't seem to be able to open those data stacks in my built application folderand examine how I did use them, as Livecode seems to open, but there is no window or sign of the stack. I'm assuming this is because of it being a substack before the build.
I have been out of this for a long time and just remember.

[dunbarx]

Hi.

You cannot access the stacks/subStacks you used to create a standalone in the actual standalone itself. You have to back to the "source" suite of stacks to do that.

Craig