The dreaded customproperties
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
The dreaded customproperties
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.
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.
-
- Livecode Opensource Backer
- Posts: 9417
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: The dreaded customproperties
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:
-
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:
-
-
- Livecode Opensource Backer
- Posts: 9417
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: The dreaded customproperties
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.
- -
The good thing about custom properties = earrings (unlike standard properties = tattoos) is that one can attach them and remove them as one wants.
- -
The good thing about custom properties = earrings (unlike standard properties = tattoos) is that one can attach them and remove them as one wants.
Re: The dreaded customproperties
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:
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.
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
...
So this is a great way to store things that the user should not see and "spit" them out when neccessary.
-
- VIP Livecode Opensource Backer
- Posts: 9678
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: The dreaded customproperties
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:
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:
Later on you can make fancier custom property sets.
Craig
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"
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"
Craig
Re: The dreaded customproperties
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.
I have been out of this for a long time and just remember.
-
- VIP Livecode Opensource Backer
- Posts: 9678
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: The dreaded customproperties
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
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