LiveCode Forums.

Hi to all;
I am using livecode Ver 8.1 and developing in windows 7 SP1.
I am an experienced developer in other high level and scripting languages but fairly new to livecode
which recently perked my interest.

I need some guidance on the following: Many forum entries I have recently followed make it quite clear that when a script is created which references a control such as buttons and fields; they should use the name property (not the label) or the assigned control ID when using them in their script of interest.

The forum entries also make it clear that you should not use numbers to name your controls to avoid scripting issues. In other words they say something like Button name = Button_1 would be a good name for the control but Button name = 3 would not be considered a good control name.

If this is in fact correct, what are these sample entries in the dictionary referring to?
“set the acceleratorKey of button 1 to "a"
OR
“set the dontWrap of field 1 to true”

1. Do the numbers here refer to something other than their control names? If so, what do these numbers mean?

2. I also noticed that livecode has assigned numbers such as”[8]” to my buttons and fields as seen when the “select object to inspect” icon is selected within the property inspector.
These numbers seem related to the control positions within my main card. Is there some possibility or situation that these numbers could be used in lieu of the control names or control ID numbers?

Thanks to all responders.

Hi Ed,

1. welcome to the forum!

2.

Do the numbers here refer to something other than their control names? If so, what do these numbers mean?

The numbers in your examples refer to the order of objects on the current card, where e.g. "button 1" is the FIRST button on the card
and FIRST means the button with the lowest layer, know what I mean?

But since the order of objects can be changed e.g. in the project browser or by script this may not be the best way to address objects.

3.

I also noticed that livecode has assigned numbers such as”[8]” to my buttons and fields...

Same as above, although I have no idea why LC does the numbering here in this way.

Hope that helps!


Best

Klaus

Thanks for such a quick response.

First can you explain the "layers" concept with respect to the control positions on the current card? I saw it mentioned in some of the forum discussions but nobody bothered to explain it and this concept does not appear in the users manual or any other resource document I have read so far.

I guess my main concern here is if these are "positional" control numbers that can change at any moment and the forum "experts" seem to agree you should not use these numbers as control object names, then why is the dictionary examples "for folks to follow and use" which is directly supported by the livecode development team, endorsing such "bad" programming usage?

The syntax of a language should be the last place where problematic examples should be presented right??
This would not be helpful the new users, saying one thing then giving examples that state the opposite.

(2) Also as a test, assuming I don't currently change any of the current control object positions, I tried using the positional numbers in scripts as stated by the “select object to inspect” icon selection (all controls are visible and do not hide any other controls) , and these numbers gave compiler errors so what does this mean if the numbers per control stated by livecode don't even work as stated? Perhaps the numbers here don't relate to the control position and really mean yet something else?

Thanks again, you have been very helpful,
perhaps your upcoming layers explanation will help me further

Personally I either refer to objects/controls by the names I have given them or their ID numbers (which do NOT change).

For example:

set the textColor of btn ID 1003 to "red"

or

set the textColor of btn "RichmondsButton" to "red"

The numbers you refer to are best avoided.

And, Yes, the Dictionary/Help System in Livecode is full of "bumf" as well as useful stuff,
and half of the "fun" is working out which is which.

Hi Ed,

Ed_Ray wrote:First can you explain the "layers" concept with respect to the control positions on the current card?

One pict says more than many words: I have made 4 controls, one after the other. The red numbers is the order in which I created them, and thus the layer.

At the left you see the properties of the selected field (2), and see that it's layer 2, and you have the controls to change this layer. Means moving them closer to you, or farther away. Comes handy when you have overlapping controls and want to have a certain in front.

And you see that the field is number 1. That's because it's the first of it's type (field) created. And this number you cannot change.

If you want to refer to our field by its number, you can do this in 2 ways:

1. field 1 [1 = number] or
2. control 2 [2 = layer]

Which means you can easily:

1. loop over all (or a certain part of) of your controls of a certain type, for instance to change the textfont of a certain range of fields;
2. loop over all (or a certain part of) of your controls, for instance to reposition them/ change the size.

This can come very handy, for instance when populating fields from a database query - especially as you can change the layer without changing the name!
The layer also determines the tab order.

Ed_Ray wrote:I guess my main concern here is if these are "positional" control numbers that can change at any moment [...]

Only the layer can change, and only if you tell it to do so!

Ed_Ray wrote:[...] and the forum "experts" seem to agree you should not use these numbers as control object names, then why is the dictionary examples "for folks to follow and use" which is directly supported by the livecode development team, endorsing such "bad" programming usage?

There's a lot of different ways of coding with LiveCode! There's a lot of young people happily coding shiny games for their gadgets, there's grave looking teachers using it in their efforts to enlighten the spoiled brats, there's great coders making useful stuff for those above, and there's some grumpy old timers grinding on boring commercial stuff, where only three things count: reliability, speed and more speed.

All these find their tools in LC, and you have found yourself stumbling over one of the "special features" beloved by the last group - yes, it's a bit hard to get, and you can make a lot of mistakes using it, so it's not recommended to use for these faint of heart and handicapped of experience.
Nevertheless it's a mighty possibility!

Ed_Ray wrote:[...] dictionary [...]

Well, it's a nice morning, the birds are singing, the release yesterday afternoon went through without major collapses - I'll better not talk of those things ;-)

Ed_Ray wrote:I tried using the positional numbers in scripts as stated by the “select object to inspect” icon selection [...], and these numbers gave compiler errors

Obviously you referenced an object with a number that doesn't exist:

• in "field 2", "2" is the number;
• in "control 2", "2" is the layer;

In the pict above there is no "field 2", because there's only 1 field on the card! But calling "control 2" gives you "field 1" ;-)

Hope I could add to the confusion, have fun!

Hi all,

@ AxWald
Thank you, that is exactly what I wanted to write!

@Ed
Here some stacks to get a quick overview about the basics of Livecode:
http://www.hyperactivesw.com/revscriptc ... ences.html


Best

Klaus

The term "layer" is in the dictionary:

Specifies the back-to-front order of objects on a card or the order of cards in a stack.

It's not an error to refer to "button 1" in syntax examples, since it just means "the first button on the card" . It's used a lot in generic examples where the specific object isn't of interest but the syntax requires a control reference. It will also work fine in your own scripts.

If you are quite sure the layering of your controls will never change there is technically no reason you can't script references using layer numbers. The problem is that layers can change as a byproduct of other commands or actions, and your script will break. Setting an object's layer to top will renumber all the other controls, as can moving an object into or out of a group. It's safer to use the ID or name because of this.

One common issue is naming cards with numbers. The command "go card 1" will always go to the first card in the stack, never to a card later in the stack named "1". Or suppose you've named a card "2016" because it contains info about this year. When you tell LC to go to card 2016 it will look for the 2016th card in the stack and throw an error if there isn't one.

Using quotes around the name can solve this, since quotes designate literals. But inside repeat loops where the card name is a variable it can fail. To avoid potential pitfalls, most of us just include at least one alpha character in every name so we don't have to keep track of any side effects.

If you are quite sure the layering of your controls will never change there is technically no reason you can't script references using layer numbers.

That seems to be where the problem lies with using numbers.

Thank you for the layer explanation. Still not clear perhaps because what I have on my properties sheet seem different than yours. Is this because we are using different versions of livecode or is it something I need to set in the preference?

I am using ver 8.1 and as you can see, my pict does not show the “number” selection alongside the layer selection yours seem to have. In addition, the front to back icon selections that should be alongside the layer item seems to be lacking.

I also do not have the visual depiction of my created controls related to the “layer” and “number” designations as shown on your right hand side of the “size and position” window. I don’t have this visual either on my right side or on any other IDE window that I could find. So imagine the confusion you would have had when you were trying to pick this concept up for the first time and this information was missing. Please advise me on what to do so that we are both on the same page as a starting point. By the way, is there a command or function that I can apply to my object of interest that would give me both the “layer” and ‘number” information? This would allow me to get at this information regardless of not having the visuals you have although the visuals would obviously be preferred.

One thing that is still confusing even after your excellent explanation is that I had located some layer information (an older dictionary with better coverage of this item) that stated that the layer related to a front to back positioning in the SAME location for that control (not what control is positioned at say the right side vs another control positioned at an extreme left position or to the bottom of that other control etc.). Yet your diagram (RED layer numbers) seem to relate the layer to where the control is positioned laterally not just front to back positioning per same control, hence the confusion.

Thanks for your upcoming clarifications

does not show the “number” selection alongside the layer selection yours seem to have

That's because the Properties palette in Livecode 8.x has been completely rejigged, and, still,
needs some work.

At the risk of sounding a bit daft; why not download Livecode 7.1.4 and play around with that
for a spot until you feel a bit more comfortable with things.

Contributors here should probably restrict screen grabs to the latest version of LC to avoid confusion. The example image is from a version that is no longer supported. I do miss the layering icons though, I used them frequently to move controls quickly to the frontmost or backmost layers. I'll see if there's a feature/bug request to restore those in LC 8.

Ed_Ray, the example image is actually two images combined. The layering image at the right side of the example is just a screenshot of the stack itself, edited in an image program to display numbers for clarity. It isn't part of LC. The part of the image at the left is a screenshot of the property inspector in LC 7 (and earlier, it wasn't changed for years.) The property inspector you see in LC 8 is the most recent version.

If you have ever used Photoshop or other apps that layer parts of an image, the concept is the same. The layer basically just determines the order that controls are drawn on the card. Layers with lower numbers are drawn before those with higher numbers, and so higher-numbered layers appear visually to be "on top" of other controls. With one exception, the layering order doesn't affect behavior at all. That exception is the tabbing order for fields; if a user types a tab to go from one field to another during text entry, and the fields have their autotab property set to true, the engine uses the layers to determine what the "next" field is.

Suppose you decide to place a background image on a card behind a number of existing controls. if the image is imported after other controls are in place, it will obscure them. Setting the imported image's layer to 1 will cause it to pop behind everything else where it should be.

The "number" field in the older property inspector identified the order of a selected object of that particular type. For example, if you had selected the third button on a card, it's layer may be 8 or 10 (because there are other types of controls on the card occupying lower layers) but it is the third control of type "button" so its "number" is 3.

The "number" keyword is most useful for iterating through controls in a loop. Usually you don't want to do something to all controls on the card, but only one type of control. You can do this by getting the "number of <control type>":
In this case the layer doesn't matter, you're only interested in doing something to each instance of a control.

If you want to affect all controls on the card, then specify "control" rather than a particular type: You can refer to controls by number in scripts, i.e., "put tText into field 1", but it's fragile because the control's layering (and therefore its number) can change. Either you'll relayer something else later on, or you'll group some controls, or something else will change, and the side effect will break the script. That's why you see repeated warnings not to depend on object numbers. It isn't because it doesn't work, it's just because it can break so easily.

Thanks to all you respondents;
You have been extremely helpful and generous with your time.

I think the main issue is that in ver 8.1, the information to understand these two numbers is literally scattered all over the place and found in unexpected places with no tie in to the two numbers, no visuals and no one place where they are readily related.

I am planning on creating a function or similar construct hopefully in the near future that "fixes" what is lacking so that all this information is found in ONE place and related in ONE place. There really isn't any reason to have all this important information scattered all over the place and remain unrelated for any new users.

It’s the difference between picking up this information in half an hour versus spending hours and days understanding how these numbers could inadvertently mess up your scripting because its lack of clarity.
Anyway that has been my philosophy in programming and scripting in other languages over many years.

The one thing I am still not getting is repeated below. Perhaps somebody can clear it up for me.
Thanks in advance to all.

What is still not clear to me?
I had located some layer information (an older dictionary with better coverage of this item) that stated that the layer related to a front to back positioning in the SAME location for THAT control (not what control is positioned at say the right side vs. another control positioned at an extreme left position or to the bottom of that other control etc.). Yet your diagram (RED layer numbers) seems to relate the layer to where the control is positioned laterally not just front to back positioning per same control, hence the confusion.

As you add objects to the card, each is considered to be on its on plane with respect to the card and the topmost one with respect to the other objects.

If you start with a new card and add 2 objects to it, the last one that you added is considered to be the topmost one. Even though they may be side by side, the last one added is considered to be on a plane above the other one. If you move either one around, you will see that this is true.

Try it and see for yourself.

As for the question on whether to use numbers for names or not, it is safer to not use them because it is too easy to get confused. (generally, if it is in quotes ("1") it is a name, otherwise it is a number.).

The problem is that multiple people are doing the documentation and everyone has a different style (naming variables, naming objects, etc). That is why people new to LiveCode often have problems. They see it in too many different ways.

Ed_Ray wrote:I had located some layer information (an older dictionary with better coverage of this item) that stated that the layer related to a front to back positioning in the SAME location for THAT control (not what control is positioned at say the right side vs. another control positioned at an extreme left position or to the bottom of that other control etc.). Yet your diagram (RED layer numbers) seems to relate the layer to where the control is positioned laterally not just front to back positioning per same control, hence the confusion.

I'm not sure which dictionary you read but lateral positions are irrelevant to layering. If the example indicated stacked controls in one location only, it was to demonstrate the idea of the top to bottom positioning.

Think of stacked panes of glass with only one control painted on each. Or geographical strata with only one fossil in each. The object can be at any x, y coordinate but the z coordinate remains the same.

I guess that would have been a better explanation actually - - a control's location on the card is its x, y coordinates and its layer is its z coordinate.

Thanks to all for the very detailed information and help.

It definitely helped to clarify the concepts that were unclear due to the lack of consistent documentation and how the needed information was/is scattered across many dialog boxes. You almost have to know livecode already to find where the scattered information is located.

I have programmed in other high level languages like C and C++ etc. and some other scripting languages like vbscript and javascript so I thought this would be a bit more straight forward etc.

No language is perfect of course but typically their syntax is very well defined and very consistent (perhaps because they have been in use longer and scrutinized by a broader audience) when compared to the livecode dictionary particularly version 8.1 where the dictionary seemed to have gotten worse when I compared it to earlier documented versions.

I keep finding many inconsistencies, errors and things that have been inadvertently left out so it makes it difficult to follow the syntax sometimes. Perhaps many of the well meaning document folks simply lacked time or were not coordinated adequately.

Anyway knowing this now I won't just blindly follow the "infallible" syntax like I typically can in other languages but will be more careful in interpreting the INTENT of the syntax when the syntax is suspect.