Go to a card using its ID

[lohill]

If I want to go to a specific card in a stack and I know its name I can use:

Code: Select all

go to card "Detail" of stack "XYZ"

and it takes me there.

If the card's name happens to be "card id 897604" the following will not take me there:

Code: Select all

put "card id 897604" into tName
go to card tName of stack "XYZ"

In the messagebox the first works and the second does not when expressed as:

Code: Select all

go to card "card id 897604" of stack "XYZ"

In the messagebox this works:

Code: Select all

go to card id 897604 of stack "XYZ"

What am I missing and how do I get there under program control?

Frustrated,
Larry

[FourthWorld]

It's probably helpful, and certainly easier, to avoid using LiveCode expressions as object names. As you've found, doing so will mean the engine has to work really hard to try to figure out what you mean, and may not always guess your intentions correctly.

If you want to refer to a card by its ID number, just write:
go cd id 12345

If you need to use an integer as a card name, to avoid confusing the engine to think you're referring to its ordinal number just put any string or character in front of it:
go cd "c12345"

[Simon]

Dosn't this;
put "card id 897604" into tName
go to card tName of stack "XYZ"
Evaluate to;
go to card card id 897604 of stack "XYZ"

Simon

[Klaus]

Not giving your cards a (meaningful) name is as a clever as using:
stack "Untitled"
field "Field"
button "Button"
etc...

[ClintMA]

I came across this rather old thread while I was looking for something similar today, and noticed that the tread did not give a direct answer to the original question.

In case someone else should be looking for an answer, here is what I have found:

It is true, as the original poster noted, that you can enter a command into the message box like this, "go to card ID 2345" and the command will behave as expected (that is, go to the specified card). However, if you want to do the same thing in a script you must format the command somewhat differently:

Code: Select all

go to card ID "2345"

Note the addition of the quotation marks around the ID number.

If you have the card ID stored in a variable (say tCardID), then you need to format the script command like this:

Code: Select all

go to "card ID" && quote & tCardID & quote

Unfortunatly, LiveCode's documentation is not very careful about explaining when quotes are needed or not. Indeed you will find examples given that are wrong or outdated or both, which is why these Forums are so useful (among many other things).

[Klaus]

Hi Clint,

numbers, and the ID of an object IS a number, do not need to be quoted!
So this will work in a script:
...
go cd id 1234
...
However, as I wrote 16 months ago, use meaningful names (in QUOTES, of course) for your objects
and these questions are meaningless

Rule of thumb:
All NAMES of objects need to be quoted, numbers don't!
...
add 1 to fld "a field with a meanigful name"
go cd id 1234 of stack "my favourite stack"
...


Best

Klaus

[jacque]

Also, quoting a number will be slower because the engine will first have to convert it from a string back to an integer.

[ClintMA]

I'm sorry that my previous post contained some misinformation.

As Klaus and Jacque said, either line of this code will work in a script:

Code: Select all

go to card ID 2345
go to card ID tCardID

What threw me off was that I was actually trying to use an indirect reference to the card ID number (neither of these worked):

Code: Select all

go to card ID item tChosen of tIDlist
go to card ID (item tChosen of tIDlist)

(I was eventually able to get a version of this to work using quotes, which lead me down the erroneous path of thinking that quotes were necessary for all scripted references to card IDs.)

The indirect reference is easily avoided by doing this:

Code: Select all

put item tChosen of tIDlist into tCardID
go to card ID tCardID

I would appreciate it someone could explain what is wrong with the indirect method I was trying to use.

With regard to the preferred use of card names rather than IDs -- I understand this, but there are situations where using card IDs are easier to work with. I am developing a stack now that has 100+ cards in it. One of the cards is randomly chosen and displayed every time the user presses the space bar. Rather than taking the time to come up with and assign 100+ unique card names, it is easier to work with the card IDs.

[jacque]

What threw me off was that I was actually trying to use an indirect reference to the card ID number (neither of these worked):

Code: Select all

go to card ID item tChosen of tIDlist
go to card ID (item tChosen of tIDlist)

(I was eventually able to get a version of this to work using quotes, which lead me down the erroneous path of thinking that quotes were necessary for all scripted references to card IDs.)

The indirect reference is easily avoided by doing this:

Code: Select all

put item tChosen of tIDlist into tCardID
go to card ID tCardID

I would appreciate it someone could explain what is wrong with the indirect method I was trying to use.

I've seen this before but I can't pin down the exact reason. For some reason the compiler won't accept the indirect reference, but you'd think using parentheses would fix that. Maybe someone else knows why. Like you, I fix it by extracting the value first before using it.

[dunbarx]

Jacque, you and I have wrestled with multiple levels of evaluation for decades, all deriving from something Dan Goodman said in the 80's. (paraphrasing) "if something seems like it ought to work, but just doesn't, try using "do" to force another level of evaluation..."

Code: Select all

on mouseUp
   put "a,b,1008,c" into temp
   do "go cd id" &&  item 3 of temp 
end mouseUp

Craig Newman

EDIT, of course, this works as well:

Code: Select all

 do "go cd id" &&  item 3 of  "a,b,1008,c" 

[FourthWorld]

Unfortunatly, LiveCode's documentation is not very careful about explaining when quotes are needed or not. Indeed you will find examples given that are wrong or outdated or both, which is why these Forums are so useful (among many other things).

The forums are indeed useful, but we should make sure the docs are top-notch too. Both the team and the community have been working together to address any errors and omissions in the docs. With a language as deep as LiveCode this isn't easy, but tremendous progress has been made.

If you find any errors or omissions in the docs please submit a bug report so they can be addressed:
http://quality.livecode.com/

And if you're inclined you can fix it yourself - this blog post explains how to contribute to the documentation efforts and includes links to tutorials for that and the docs source on GitHub:
https://livecode.com/putting-the-you-in-documentation/

[jacque]

Jacque, you and I have wrestled with multiple levels of evaluation for decades, all deriving from something Dan Goodman said in the 80's. (paraphrasing) "if something seems like it ought to work, but just doesn't, try using "do" to force another level of evaluation..."

True, but I go to extreme lengths whenever possible to avoid "do" . Adding a single line of code is easier on the engine and runs faster because it doesn't require the compiler to load. It's also easier on the developer to avoid all those quotes and ampersands.

I've put "do" into the same box with global variables. Sometimes necessary but only as a last resort.

[dunbarx]

Jacque.

I am often with you, though I use "do" when it is not too cryptic.

Jacque means something like this, the extra line also "forces" another level of evaluation (sorry for all the "gets":

Code: Select all

 get "XXX,1009,ZZZ"
   get item 2 of it
   go cd id it
   
-- this is the short way

   get "XXX,1009,ZZZ"
   do "go cd id" &&  item 2 of it

With large monitors these days, extra lines are not too onerous.

Craig

[FourthWorld]

Goodman wasn't using LiveCode. More flexible object references, arrays, and other language features make "do" useful in far fewer cases. Goodman's rule still applies, just less often.

[dunbarx]

Richard.

Goodman wasn't using LiveCode. More flexible object references, arrays, and other language features make "do" useful in far fewer cases. Goodman's rule still applies, just less often.

Just so, but I have always found it odd, and oddly comforting, that the tricks we used in HC to squeeze out additional functionality also are just as pertinent in LC. In other words, I am always surprised how close the two environments are; the fact that LC is a massive superset of HC notwithstanding, its HC roots seem embedded very deeply.

Craig