How to distinguish between label and fields

[ZSGoEmpire]

I currently creating a script that will clear all values in all fields in each card of each stack. My problem is how will I distinguish if the control is a label or field so that I my script will not include labels during clearing. Is there a property or a way to differentiate labels and other fields?

[SparkOut]

Labels are only fields with certain properties set, so the only way is to give all your fields and labels a distinctive name such as prefixing with fld or lbl respectively. You might look at the locktext property, this is set by default for a label. It may be useful but not definitive.

[AxWald]

Hi,

it's not set as default, but you can use the "cantselect" property to distinguish:
it's the small lock icon in the project browser, and setting this (true) for labels & clearing it (false = default) for fields actually suits the common workflow - you rarely need to interact with a label in a finished stack.

Have fun!

[dunbarx]

Hi. Setting up your label fields with some reliable property is a good method. The showBorder? Just for laughs, I made a label field and an editable field with the sane rect. In a button:

Code: Select all

on mouseUp
   put the properties of fld 1 into f1
   put the properties of fld 2 into f2
   combine f1 with return and comma
   combine f2 with return and comma
   
   repeat with y = 1 to the number of lines of f1
      if line y of f1 <> line y of f2 then put line y of f1 &&  line y of f2 & return after temp
   end repeat
end mouseUp

Looking at temp, (Your temp will have different locs, names and rect. That sort of thing) is there a reliable, and that is the key operative word, difference in properties that you can, er, rely on? I like the showBorder.

Craig Newman

[AndyP]

I've got into the habit of prefixing all my controls thus:

FldName

LblName

BtnName

GrpName

etc...

This way I find it easy in code to see what type of control I am referencing and also I can do a loop through all of the controls looking for the prefixes.

[ZSGoEmpire]

Thank you very much for your feedback. I'm sorry I forgot to mention that I am assign to an existing project that was handled by a lot of programmer before me. Sad to say a lot of them does not follow our naming convention, that is why I was having a hard time finding ways to clear all fields in each card. The project has a lot of stacks containing a lot of controls. If I will change all controls name not to mention tracing the name in all codes, it will take me forever to finish this.

Is there a way we can distinguish if that control is a field or label by running a script?

Thanks in advance

[Lagi Pittas]

Hi

Just did a little test and its not what IO expected

i installed a button a textfield called "afield" and a label called "alablel" on my stack with the code as below.

Code: Select all

on mouseUp
   local  ff, ll
   
   put the properties of field "afield" into ff
   put the properties of field "alabel" into ll
   
   put the keys of ff
   put the keys of ll
   
end mouseUp

I expected

I expected a list of properties being almost the same for a label and a text box -- NO cigar.
The 74 properties are exactly the same.

What I then did was made a best guess of what properties might be false in the majority of cases for a label than a field and I was correct unless
you have real UI problem where people travers onto labels.

So if you find all controls where the traversalon property is set to false I'm pretty sure they will be labels.

You might get a few textboxes set to false for some reason but it will be pretty few and far between.

The default style of a label is transparent but for a textbox it is rect so that could home in on all the labels.

Hope this helps.

As it is, I start the names of all my labels with lbl and field with "fld" or "txt" depending on wether the textbox is updateable by the user or via script

Regards Lagi

[dunbarx]

Hi.

Do I understand that you only looked at the keys of each array? And did not check the values associated with each?

It is true that the "properties" of any kind of field are identical, but it is not true that the properties are. A little cute, but do you see what I mean?

Craig

[FourthWorld]

A label is a non-editable field. Lots of other ways to handle this too, but that one distinction is simple and universal; see the lockText property.

[Lagi Pittas]

Hi

This was a start
I specifically didn't mention lock text because I use that a lot in my programs to stop users accidentally editing
Records without specifically pressing an edit button
I'm sure there are other properties but I would guess those two would cover 99% of the cases
Would have been easier if ther was a propert on all objects saying what they were though

Lagi

[dunbarx]

Would have been easier if ther was a propert on all objects saying what they were though

There is. The "properties". we both spoke of that above. What would you like to see in such a gadget that is not already there?

Craig

[Lagi Pittas]

I can't see any property that's is either specific to
A label or a text box -- they are all the same. I was talking of s property maybe
Named say objtype that the system sets to Txtfield or lstbox Or lblfield etc. It's not really a problem
If you have a naming convention but as the op said ... he has inherited crud.
Which property did you mean Craig that already exists?

Lagi

[[-hh]]

When I need that, my method is to set 'the type' of a field, a customProperty: one of "label,list,text,whatever".

This is an easy to remember customProperty if a resetting is needed whenever the "type/style" of the field changes.

Code: Select all

set type of fld 1 to "label"
if the type of fld 1 is "label" then do empty

[dunbarx]

Which property did you mean Craig that already exists?

I did not mean that there was a unique property that only label fields have. There are none. They are, as Sparkout mentioned, just fields, the same object class as, er, fields. So you must manage any reliable distinction yourself. Naming conventions, reliable differences (properties) between label fields and all other fields, a custom property, as Hermann suggested, whatever.

Perhaps the showBorder is not really reliable, as I had mentioned above (this was before we knew that you had inherited the work of others). In any case, you will have to find every field and assign some characteristic that distinguishes only label fields. This should not be too onerous, needs only be done once, and then you follow that convention going forward.

Craig

[jacque]

If using locktext isn't enough you can check for three properties that all labels have:

locktext = true
autohilite = false
traversalon = false

A field that has all three of these property values is likely to be a label. There are exceptions, a locked field with the last two properties set to true allows the text to be selected and copied but not changed. This is fairly rare though.