How to distinguish between label and fields

[MaxV]

For example:

########CODE#######
on mouseUp
put the number of fields of this card into nnn
repeat with i=1 to nnn
put the lockText of field i into tlt
if tlt is true then
put the abbreviated name of field i && "is a label" & return after risultato
else
put the abbreviated name of field i && "is a field" & return after risultato
end if
end repeat
answer risultato
end mouseUp
#####END OF CODE#####

[dunbarx]

I would add an unassailable distinction to label fields. That is going to either be a name convention or a custom property.

Nothing else will be do with certainty, that will not possibly bite you down the road.

Craig

[AxWald]

Hi,

I would add an unassailable distinction to label fields. That is going to either be a name convention or a custom property.
Nothing else will be do with certainty, that will not possibly bite you down the road.

Quoted for truth.

"LockText" will bite you at the latest when you add any fields that should respond to mouseUp or mouseDoubleUp (usually to select parts of it).

So better set a custom prop for your label fields only:

Code: Select all

if not the dontTouchMe of fld myFld then put empty into fld myFld

If you still must use a built in property, choose at least one that:

• is most rarely used elsewhere
• is easy to view & control via application/ project browser
• is false as default
• and doesn't have nasty side effects, even after thinking twice.

For me this leaves only one candidate:

Code: Select all

if not the cantselect of fld myFld then put empty into fld myFld

Have fun!

[dunbarx]

Or, more directly:

Code: Select all

if the iAmIndeedALabelField of fld "soAndSo" is "true" then...

Craig

[FourthWorld]

The cantSelect is a highly specialized property, implemented by Dr. Raney at my request many years ago as a temporary workaround for not having discrete tool modes for groups. Recently I had recommended it not be given such prominence as it currently has in the latest builds of the Project Browser, because it's so unusual, cumbersome to work with, and rarely needed, and the space could be better used for the much more commonly-used lockLock, but my suggestion was overridden. Oh well.

While nearly any non-visible property could be used as a flag for scripts to distinguish a control, using cantSelect carries the significant downside of not allowing the developer to use the pointer work with the control as they do any other.

If lockText is insufficient for a given scenario, just use either a naming convention (I often preface labels with "lbl") or a custom property.

Any solution will requiring setting a value in a property, so whether that property is built-in or custom doesn't really change the number of steps during development.

[marksmithhfx]

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.

Thank you Richard. I had been looking for that distinction and since lockText is not a property I ever mess with this should work perfectly for distinguishing between a label and a regular field. If it isn't, I'll let you know.

[marksmithhfx]

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.

I had to think about this long and hard but since what I am trying to distinguish between are fields that are modifiable, and fields that are not, checking lockText seems to be the most reliable way. So for me lockText is now synonymous with "is-a-Label". If lockText is true the field is a label.

Mark

[dunbarx]

Mark.

Reviving a 7-year-old thread?

You did not like my

Code: Select all

if the iAmIndeedALabelField of fld "soAndSo" is "true" then..

The point of that silliness was that if you really want to distinguish a label field from just a field that has it s text locked you need more properties, as Jacque pointed out. But my real question is why and how does it matter? A label field has a certain look and feel, apart from its properties. If that is not all of it, then what are you really after?

Craig

[marksmithhfx]

Mark.

Reviving a 7-year-old thread?

You did not like my

Code: Select all

if the iAmIndeedALabelField of fld "soAndSo" is "true" then..

The point of that silliness was that if you really want to distinguish a label field from just a field that has it s text locked you need more properties, as Jacque pointed out. But my real question is why and how does it matter? A label field has a certain look and feel, apart from its properties. If that is not all of it, then what are you really after?

Craig

Hi Craig, I am trying to develop a no-code interface to LC, especially for integrating Sqlite. But the UI (fields and whatever) are entirely up to the user. I can't dictate what they do but have to try and interpret what they do. This is an evolving process but I am thinking that in the first instance I want to ignore labels and focus on fields that actually do want to make their way into a database. Perhaps. Nothing is perfect. But at the moment, that seems like a good place to start. I am not going to try and educate and train users, rather, be prepared with anything they throw at me.

I don't have you on my short list but if you want to provide feedback very happy to add you to the next iteration (It would be an honour).

All the best,

Mark

[dunbarx]

Mark.

I would be happy to, but I never use databases of any kind, so I do not think I would be of any help.

Caig

[marksmithhfx]

Mark.

I would be happy to, but I never use databases of any kind, so I do not think I would be of any help.

Caig

Perfect . You are now added. Some of the best testers are those who have no experience.

Mark

[dunbarx]

...those who have no experience.

Well then you picked the right guy.

Craig

[mwieder]

Hah! I was just looking at natural language database queries.

https://dev.to/ngonidzashe/speak-your-q ... tabase-p62

[marksmithhfx]

Hah! I was just looking at natural language database queries.

https://dev.to/ngonidzashe/speak-your-q ... tabase-p62

Hi Mark,

I would agree with you but the assumptions here are quite remarkable...

I am already assuming that you have postgresql installed on your device and have an open ai account. We are going to use the python-environ module to manage the API keys and database password.

I cannot fathom anyone who is interested in average end-users having these assumptions met. It's beyond belief. This is totally aimed at a very sophisticated user base of hundreds, perhaps even just dozens. How does any reasonable human being believe that the reader would have such a sophisticated infrastructure enabled? I consider myself a fairly sophisticated LC user and I have none of this installed or even understand what it means (ie. a python-environ module to manage API keys). This person is speaking mostly greek to me.

When I write code, I want it to be accessible to everyone, regardless of prior knowledge or sophistication. It should be understandable from the point of view of a relatively sophisticated VCR user ie. no more complicated than recording your average home video. If you get more complicated than that then you are going to lose most of the population.

My two cents on the topic of "ease of use".

Mark