Stacks whose names start with "rev"

[Geoff Canyon]

FileMaker goes much deeper than this, and functionality like this would
almost have to be part of the engine.

Naming things is a way of making it easier to keep track of them for the
developer. Who wants to write

graphic id 5621 of group id 5619 of group id 5615 of group id 5605 of group
id 1282 of card id 1002 of stack "/Users/gcanyon/Documents/My
Livecode/Plugins/Navigator.rev"

when you can just write

graphic "topright in"

So for starters, you'd need to parse every script as it was saved, find all
the object references, and replace all object references with long IDs.
Likewise, you'd need a reverse routine to turn scripts back into something
readable when the developer wants to edit them. That's easier in FileMaker
because there is only one way to reference a control, as opposed to the
myriad of ways you can do it in LiveCode. You'd also need to find a way to
make that robust against file name/path changes, which is a whole other can
of worms.

Also, I don't think FileMaker "has" to do it -- there are many database
tools out there, and as far as I know, none of them do this.

On Wed, Oct 3, 2018 at 8:34 AM Bob Sneidar via use-livecode <
use-livecode at lists.runrev.com> wrote:

> It would be easy enough. Just maintain an array in each card's custom
> properties with a pseudoname and the long id as keys, and call a function
> to retrieve them when you reference them. But then, why name objects at
> all? Why not just refer to them by their long ids in the scripts? Also
> there is the altid property which allows you to copy an object and still
> refer to it by it's altid wherever it is found.
>
> And, thinking about this a bit, whenever I get the chance I iterate
> through a series of objects either by using the number of <objectType> in a
> repeat loop, or else by storing them in a property when I need them. I
> guess these are forms of abstraction. I went through all my code and
> "dereferenced" it in preparation for moving to behaviors. I store any
> objects I need to reference specifically in custom properties.
>
> For instance I have what I call a name tag field, which is a label
> indicating what the parent of a form is (the site a device belongs to, the
> customer a site belongs to etc.) So I store a custom property in the card
> or stack where the cNameTagField property is the name of the field. To
> avoid multiple calls to "get the <property> of", I store all such
> properties in a single array, get the array one time and populate script
> local variables. Another form of abstraction.
>
> I guess the reason Filemaker has to have this automatic abstraction is
> because the database and underlying form objects are so closely linked. It
> really wouldn't work any other way. In livecode, the only link between a
> database column and a field or button is the code you write.
>
> Bob S
>
>
> > On Oct 2, 2018, at 15:30 , Geoff Canyon via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> >
> > The fact that there is an underlying permanent unique id for everything,
> > completely abstracted from the user. So you can change the name of a
> > column, or table, or layout, one time, in the database definition, and
> all
> > references to that object in scripts, other layouts, etc. will
> > automatically update -- or really, peeking behind the curtain, I'm
> guessing
> > they don't have to update at all because they all reference the permanent
> > unique id, and only render it into the name you know it by when they
> render
> > themselves for you to edit them.
> >
> > So in LiveCode terms, imagine if you could rename a card, and any script
> > that referenced that card, or controls on it, wouldn't break, but just
> > automatically reflect the new name. Or rename a control, or a stack.
> >
> > gc
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>