selectedText

[dalkin]

I have a situation where I populate a scrolling list field with text from another card and it works fine (for navigation) but I've noticed that if the "text" is, in fact, a number sequence, the selectedText command doesn't seem to work. Is this expected, or am I a complete idiot?

[jmburnod]

Hi,
I tested it (LC 9.0.1) like this:
field "fMyListFld" script:

Code: Select all

on mouseup
   put the selectedtext
end mouseup

It works for me with a line "1234", i get "1234" (also with 12,34 i get 12,34)

Code: Select all

put the selectedtext of fld "fMyListFld"

from message box works too
Best regards
Jean-Marc

[Klaus]

Is this expected, or am I a complete idiot?

Show us your script(s) and maybe then we can tell you.

[dunbarx]

Hi.

LC does not know the difference between letters and numbers, in the sense that both are simply ASCII characters, and a function like the "selectedText" will be blind to the actual makeup of the text of interest.

Also, not sure what you meant about "navigation". I am with Klaus; we need to see what you are up to.

Craig

[dalkin]

Thanks all. I have attached a sample stack that contains 2 cards. In the runtime environment, the first card has 3 components so clicking on "New Project" takes you to the 2nd card where you see a field where you can name the Project.

Giving the Project an alphabetical name returns its name to the scrolling text field on the first card and if you add a few of these, they populate the list field and respond to a selectedText instruction which takes the user back to the named card.

But giving the Project a string of numbers (eg. 1111 or 2222 etc.) populates the scrolling text field but doesn't, in turn, respond to a click.

The project is relying on a cloneCard script which you will see in the browser as they are named and added.

Please note that at the moment, functionality requires a return or enter in field when the new project is named. This sets the name of the clonedCard which is eventually referenced by the scrolling list field on the first card (accessible via the 'Navigation' button).

Data Save.livecode.zip

(2.54 KiB) Downloaded 175 times

[FourthWorld]

I found the issue. The list is working well, but the problem is you're naming a card with an integer. Purely numeric names are problematic in a language like LiveCode which also allows you to refer to objects by their ordinal number.

So when you have the string "2222" as a card name, having "2222" in the variable tCard and using "go cd tCard" is asking LC to go to card number 2222. And unless you have 2,222 cards in your stack, it'll fail.

One thing to do is finish the error-checking in that handler. You test for the existence of a card matching the name of the selected text, but provide no feedback if one isn't found. This adds that:

Code: Select all

on mouseup
   ## put the complete selected line into a variable
   put the selectedtext of me into tCard
   ## ALWAYS do checks like this, you are now the programmer and repsonsible for EVERYTHING
   ## Especially if the USER screws up, it is all YOUR fault! :-D
   if there is a card tCard then
      ## There is a card with that name, so we simply go to that card.
      go cd tCard
   else
      answer "No such card"  -- NEW
   end if
end mouseup

Another thing is to avoid number-only names for objects. Whether you disallow that in the field or accept the contents of the field and prepending it something non-numeric (e.g. "card_2222") is up to you.

Bonus: You may find it easier to populate your navigation field freshly each time you go to the card. It avoids having to add anything to the list as they're created, and ensures the list is complete. And it's superfast with the cardNames function:

Code: Select all

on preOpenCard
   put the cardNames of this stack into fld "Index"
 end preOpenCard

One nice thing about a complete list of card names is that you don't need to use the card name at all to navigate to it, you can use its number, which will correspond to the list field's hilitedLine:

Code: Select all

on mouseUp
   go cd (the hilitedLine of me)
end mouseUp

[dunbarx]

This comes up all the time. We need a short lesson to refer people to.

There are excellent reasons to base object names on numbers. For example, imagine you have three fields named "f1", "f2" and "f3". In a button script, say, place this:

Code: Select all

on mouseUp
   repeat with y = 1 to 3
      put (y * 10) into fld ("f" & y)
   end repeat
end mouseUp

Click the button. Very compact. But note that the name of each field is not simply a number, even though the numerical part of each name is the only thing that matters. This is the point Richard made, that with a numerical parameter, LC will look FIRST at the layer order of a control, and not at the name of a control.

Hmmm. If I wrote such a lesson, where would I best place it?

Craig

[FourthWorld]

This comes up all the time. We need a short lesson to refer people to.

I send them to p141 of the User Guide, in the section listed in the TOC as "Avoid using numbers as object names", in the chapter "Referring to Objects".

They added that a couple years ago at my suggestion on behalf of you and others here who see this come up often.

If we could do it all over again, the best solution would be to simply not allow the "go" command to be used for ordinal references without an explicit modifier, maybe "go card number 4"; without the "number" modifier "4" would be assumed to be the name.

But it's been too long since the HC team established the ambiguous convention of allowing both name and ordinal references using identical syntax, so it's probably too late to change it now. It's so unintuitive we can expect to see this question again. Oh well, every language has its oddities. ::sigh::

[dalkin]

Many thanks Craig and Richard.