Running U b u n t u 1 6 . 0 4 LTS.
Wrote a script in a Default Button that would move a value to a field.
Adding and removing fields I can not figure out if the Put "whatever" into fld XXXX is the "Name" of the field (under the Basic tab)
or if it is referencing the "Number" of the field (under the Advance tab). I can not change the "Number" of this field.
Sometimes it works sometimes it doesn't. I'm confused, shouldn't it reference the "Name" (in the Basic tab) of the field.
Also dropped a "Label" on the card and the "Contents" (under the contents tab) Always resets to nothing after closing the Stack.
Other labels (same Stack) Hold their values. Why?
LC version 9 . 0
Ref Fields
Moderator: Klaus
Re: Ref Fields
Hello e_mail8086,
Whether you are talking about fields, or really any object, there are several ways to refer to them in code. The two easiest ways are by name (and you really should name your controls with good solid names), or by number.
For instance, here is a very bad naming example - - however, you *could* still distinguish between all these fields by using their number (which is pretty much going to be the same as their order in the project browser on the side there). To demonstrate, I'll make them number themselves in code -
The result is that the fields are numbered in the order they were placed on the card, which is how you see them displayed in the project browser.
However, as I said above, having 8 fields named "field" isn't exactly optimal programming. What you want is a consistent and, hopefully descriptive, naming scheme for all your controls. Many people just name their controls with names that make sense to them, like field "Name", or field "Color", and that is fine.
My preference is to use names that are a bit more precise, though. If I'm using the field for a label, for instance, I'd name it field "lblName" or some such. If it is going to hold editable text, it would be field "txtMemo", for instance. This is a holdover in my case from earlier languages I've used, I find it quite handy.
When referring to a control by name, it is better to enclose the name in quotes, as you see in the above examples. In this last code example, I will make the fields put their names after their number. Just to drive home the number part of it, I've also rearranged their position on the card, so that you can see that has no bearing on when the field was created.
Here you see the result -
Whether you are talking about fields, or really any object, there are several ways to refer to them in code. The two easiest ways are by name (and you really should name your controls with good solid names), or by number.
For instance, here is a very bad naming example - - however, you *could* still distinguish between all these fields by using their number (which is pretty much going to be the same as their order in the project browser on the side there). To demonstrate, I'll make them number themselves in code -
Code: Select all
on mouseUp
repeat with x=1 to the number of controls of this Stack
if word one of the name of control x is "Field" then put the number of control x into control x
end repeat
end mouseUp
My preference is to use names that are a bit more precise, though. If I'm using the field for a label, for instance, I'd name it field "lblName" or some such. If it is going to hold editable text, it would be field "txtMemo", for instance. This is a holdover in my case from earlier languages I've used, I find it quite handy.
When referring to a control by name, it is better to enclose the name in quotes, as you see in the above examples. In this last code example, I will make the fields put their names after their number. Just to drive home the number part of it, I've also rearranged their position on the card, so that you can see that has no bearing on when the field was created.
Code: Select all
on mouseUp
repeat with x=1 to the number of controls of this Stack
if word one of the name of control x is "Field" then put the number of control x & space & the name of control x into control x
end repeat
end mouseUp
