Referencing Objects of the Same Name

[townsend]

Livecode lets you create as many objects with the same name as you want.
I've looked all over, but I can't seem to find how to reference these objects individually.

Code: Select all

put "hello world" into fld "test" 3
put "hello world" into fld "test"[3]
put "hello world" into fld 3 "test"

None of those work. I do know, if the ID's of the objects are sequential, you can reference all of them with a Repeat loop, by ID. But if the IDs are not sequential, and only you have only identical names, is there some way they they can be referenced in a Repeat loop?

[Klaus]

Hi townsend,

Referencing Objects of the Same Name?

no way!

LC will always take the first object with that name (= the object with the lowest layer),
and you cannot do anything about this.

Livecode lets you create as many objects with the same name as you want.

Yes, but doing so is a bad idea!


Best

Klaus

[Simon]

Hi townsend,
I'm with Klaus you shouldn't use the same name for objects.

But I'm going to answer two problems at once

Code: Select all

repeat with x = 1 to the number of fields of this cd --this will affect EVERY field on the card
set the label of field x to "textFld"&x --The lowest layer field is field 1 next up is field 2 etc.
end repeat

There they now all have unique names and I reference them in a loop even though their names were the same.

I'm pretty sure Klaus will be mad with me because there is no way that you should ever have objects with the same name even if you can reference them Bad programmer no biscuit

Simon

[dunbarx]

What everyone said.

But you can see the pitfalls of this yourself, even though in some projects it might make no difference. Names are not always the primary vehicle to reference objects, however, and as Klaus noted, layer order has been more convenient for me on many occasions.

And if you do not fool around with them, id's are immutable and available for this purpose. Immutable unless you change them. Sheesh.

Craig

[Klaus]

Hi Simon,

I'm pretty sure Klaus will be mad with me because there is no way that you should ever have objects with the same name even if you can reference them

well, only mad because of your missing PARENS: %]]$#??it
...
set the label of field x to ("textFld" & x)
...


Best

Klaus

[dunbarx]

well, only mad because of your missing PARENS: %]]$#??it
...
set the label of field x to ("textFld" & x)

Though this is absolutely good practice, it is not necessary.

set the label of someObject to "literal" & variable

works fine. Always did. Thank HC for the flexibility that can be misused if you are not careful

Craig

[Klaus]

Hi Craig,

well, it might work in this situation, but I have experienced cases where this did NOT work as exspected!
So maybe I am a bit more cautious that neccessary.

Although I am german I do not script "the officical way" because it is "official" , my scripting style
is rather the result of my experience in working with LC and its ancestors (MetaCard/revolution) with
all their PROs and CONs since 1999.


Best

Klaus

[dunbarx]

Klaus.

I am with you. Sometimes it seems that code which worked in one script do not in another. though they seem mainly identical.

I think not placing parens in the poster's case is lazy and dangerous. Just making the point, really, that the flexible syntax is, well, really flexible.

And I have you by 12 years. In those early days, I used to exploit the looseness of Hypertalk. Seemed like a gift. Now it makes me pause.

Craig

[Simon]

Oh the shame...
Shame....

Simon

[FourthWorld]

...if the IDs are not sequential, and only you have only identical names, is there some way they they can be referenced in a Repeat loop?

The key question may be why do the controls all have the same name?

If that's for the benefit of the user, remember that in LiveCode every control has both a name and a label property. The label is what's displayed in a button, and if it's empty it will display the name.

But you can use them completely independently of one another, setting the label to anything that makes sense for the user while setting the name to something that has some mnemonic and/or scripting value for yourself.

So if you set the label of each button to "test", you can set their names to "test1", "test2", etc, and then use a loop as the others here described to walk through them.

With fields, however, neither the label nor the name is ever displayed to the user. Only the field's contents are displayed, so using the name for your own scripting benefit will not affect the experience for your end users in any way.


As for parentheses, I started to write a reply but got too long (a bad habit of mine), so I added that as an article to LiveCodeJournal.com instead:
http://livecodejournal.com/tutorials/wh ... ecode.html

[FourthWorld]

I used to exploit the looseness of Hypertalk. Seemed like a gift. Now it makes me pause.

The difficulty with HyperCard is that it died too young. Like a child's untimely death, the world is denied the chance to see what might have become of her had she lived a full life.

Where LiveCode is stricter than HyperTalk, it generally means much greater performance.

Being able to override built-in functions, for example, is something that I took for granted with HyperTalk, but when I noticed that the option was missing in LiveCode (still called MetaCard in those days), I complained to the owner at the time, Dr. Raney. Not a shy one, he clearly explained the impact on the token lookup table and how that would impair performance, and then went on to note that if we need custom behavior we might just as well use a custom name, esp. given that if used in a library a custom function might break upstream scripts that relied on the standard engine behavior.

I argued with him, and he was ultimately willing to offer a compromise, in the form of a challenge: if I or anyone else could find a reason why it would be necessary to have custom behavior for a function that must have the name of a built-in function, he'd add support for that.

I took his challenge to the community. None of us could ever come up with one.

So the token table remains lean, scripts are never broken by custom function definitions in libraries, and although it carries several times more language tokens LiveCode blows the pants off HyperCard in nearly every area of performance (the find command being among the very few exceptions we've been able to identify).

Because the proposed "Open Language" syntax will be, AFAIK, based on a system of well-defined prototypes, it may be able to take care of many of the current cases where parentheses are currently needed. But I'll have to see it before I get too excited about it beyond that and making externals and custom handlers more readable.

It seems that the phrase "open scripting" has lent itself to being interpreted as "anything goes", but I doubt RunRev would go so far as to make it possible for developers to invent confusingly dissimilar syntax.

Moreover, Raney's warning about overriding built-in tokens in terms of scripts that rely on standard engine behavior is still potentially an issue if not handled with extreme care.

[SparkOut]

I started to write a reply but got too long (a bad habit of mine)

No, no, your well written insights are always worth reading.

[Klaus]

Oh the shame...
Shame....
Simon

Yeah, the glorious "Disco" days: http://www.youtube.com/watch?v=YSR0bvCPf2M



Best

Klaus

[jacque]

I argued with him, and he was ultimately willing to offer a compromise, in the form of a challenge: if I or anyone else could find a reason why it would be necessary to have custom behavior for a function that must have the name of a built-in function, he'd add support for that.

I took his challenge to the community. None of us could ever come up with one.

Well, I did, but it was an edge case and he didn't buy it. It sure would have made my life easier though.

[townsend]

The key question may be why do the controls all have the same name?

I'm using the Charts Engine plugin. Rather than use the automatically generated legend, I've created a series of Option Menu Buttons for each line in the chart, with various functionality.

Anyway, I've been calling these Buttons: Line1, Line2, Line3 ... Line10. I thought that maybe I could combine the root of the name, 'Line' with a numeric variable, and be able to easily reference these controls by name, in a loop. That didn't work either.

Interesting idea about setting the object Label to a unique name that can later be references by running though the list of all objects. Though with Buttons, using the object's Label isn't practical. Couldn't the same thing be done by creating and referencing a Custom Property for each object?