Dumb Newbie Questions -- 1 of N

[Kay C Lan]

On Sat, May 2, 2009 at 3:55 AM, Mark Swindell <mdswindell at cruzio.com> wrote:

> While "property" might not be the best name, I can't think of a name better
> suited, since  custom properties are persistent across sessions,
>  proprietary to an object, and the syntax is consistent with other object
> properties...  the height, the width, the visible, the cpWhatEver of button
> x.  It seems pretty simple and straightforward.  What isn't intuitive is
> that a custom property can contain a stack, for example.  Cool, but not
> intuitive.   I mostly use them to keep variable contents or states  alive
> across sessions.
>

Basically with you Mark except I do think that Custom Property is a very
good name :-)

IMO what isn't intuitive is when you can use them, especially use them to
your advantage. When I read the explanations by others above what I see is
people saying 'I can use them like a field (hidden)' or 'I can use them like
a global' they are not really explaining what they are, but how they have
come to use them.

Scott wrote:

In my example, I used a global analogy because 1) setting/modifying custom
properties do not inherently make any visible changes in an object, unlike
textColor or other built-in object properties;


Whilst this is generally true, there are object properties that don't have
an immediate visible effect, such as the dontSearch, travesalOn or autoTab
of a field or the acceleratorKey of a button. Stacks come with alwaysBuffer,
destroyStack and cantDelete. Then there are the really invisible properties
such as itemDelimiter and defaultFolder. If you can understand and work with
these you can work with Custom Properties.

Richmond wrote:

The term 'custom property' is misleading; it is like asking "Where is
> Axminster?" and then
> wondering why they don't show you the bathroom.
>

What? This is like saying  I "put the itemDelimiter into oldDelim" and am
now wondering why oldDelim doesn't contain the path to the defaultFolder.
There is nothing misleading about what a property of an object is, when you
ask for an object's property you get that property back, be it an inbuilt
property or one you've created.

Judy lamented:

--Well, yes, especially that last part, wherein I felt rather like I was
> being asked to interact with invisible magic things, only, when they're
> invisible how will I know them when I see them?  I mean, I literally didn't
> know what step 1 was supposed to be.  I had a vague, fuzzy notion of what
> they were supposed to do but not how they did it.
>
> So, anyway, I did one.  Yay me!
>
> I dunno... I still like cards.  I like things that I can see, have mass
> and/or take up space. ;-)
>

But you can see them, they do have mass and take up space, there is an
entire Property Inspector tab devoted to the space taken up with custom
properties you create.

You can't see the raw htmlText of a field, but if you can get your head
around how that magic works you should find custom properties a lot easier
to work with because you can look at them and see exactly what they are.

You can get and set the text of field 1 (inbuilt and visible in the PI)
You can get and set the htmlText of  field 1 (inbuilt but not visible as raw
html in the PI)
You could create the xmlText of field 1
You could create the csvText of field 1
You could create the englishText of field 1
You could create the latinText of field 1

The last four cases would be visible in the PI and could be edited from
within the PI (unlike the htmlText), they are very real, and if you fill
them with the complete works of William Shakespear, they'll take up a lot of
space.

With enlishText/latinText, you could, depending on user interaction, display
the text as is:

 set the text of field 1 to the latinText of field 1

Or, in the case of xmlText/csvText, parse the text before displaying it,
much like the Engine currently does for htmlText

put the csvText of field 1 into tempStore
replace comma with tab in tempStore
set the text of field 1 to tempStore

Again, when your Ah Ha moment comes you'll know exactly what custom
properties are, how to work with them, how to see their contents,
everything, because you have already been working with the magic of
properties and the PI for a very long time. The only magic you don't
understand right now is what you are doing right now that could be done with
custom properties.

My analogy for custom properties is they are like properties that you don't
know exist. Take the defaultMenubar for instance. You could spend years
makeing the exact same menubar for all your MainStacks and subStacks. It
works for you, they are real, you know how to amend them - it's a lot of
work in you need to add a menu item to the menuBar of 7 substacks.

When someone tells you that there's a property 'the defaultMenubar' which
allows you to build one menuBar and have it appear for any substack you know
you can use that to your advantage, you know how to use it because you've
used other properties. You'll also wish someone told you about it  years ago
;-)

HTH