How to distinguish between label and fields
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
Re: How to distinguish between label and fields
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#####
########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#####
Livecode Wiki: http://livecode.wikia.com
My blog: https://livecode-blogger.blogspot.com
To post code use this: http://tinyurl.com/ogp6d5w
My blog: https://livecode-blogger.blogspot.com
To post code use this: http://tinyurl.com/ogp6d5w
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: How to distinguish between label and fields
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
Nothing else will be do with certainty, that will not possibly bite you down the road.
Craig
Re: How to distinguish between label and fields
Hi,
"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:
If you still must use a built in property, choose at least one that:
Have fun!
Quoted for truth.dunbarx wrote: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.
"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
- 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.
Code: Select all
if not the cantselect of fld myFld then put empty into fld myFld
All code published by me here was created with Community Editions of LC (thus is GPLv3).
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
If you use it in closed source projects, or for the Apple AppStore, or with XCode
you'll violate some license terms - read your relevant EULAs & Licenses!
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: How to distinguish between label and fields
Or, more directly:
Craig
Code: Select all
if the iAmIndeedALabelField of fld "soAndSo" is "true" then...
-
- VIP Livecode Opensource Backer
- Posts: 9856
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: How to distinguish between label and fields
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.
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
- Location: London, UK
Re: How to distinguish between label and fields
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.FourthWorld wrote: ↑Sun Dec 11, 2016 7:08 pmA 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.
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
- Location: London, UK
Re: How to distinguish between label and fields
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.jacque wrote: ↑Mon Dec 12, 2016 5:37 pmIf 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.
Mark
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: How to distinguish between label and fields
Mark.
Reviving a 7-year-old thread?
You did not like my
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
Reviving a 7-year-old thread?
You did not like my
Code: Select all
if the iAmIndeedALabelField of fld "soAndSo" is "true" then..
Craig
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
- Location: London, UK
Re: How to distinguish between label and fields
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.dunbarx wrote: ↑Tue May 02, 2023 2:51 pmMark.
Reviving a 7-year-old thread?
You did not like myThe 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?Code: Select all
if the iAmIndeedALabelField of fld "soAndSo" is "true" then..
Craig
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
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: How to distinguish between label and fields
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
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
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
- Location: London, UK
Re: How to distinguish between label and fields
Perfect . You are now added. Some of the best testers are those who have no experience.
Mark
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS
-
- VIP Livecode Opensource Backer
- Posts: 9751
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: How to distinguish between label and fields
Well then you picked the right guy....those who have no experience.
Craig
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: How to distinguish between label and fields
Hah! I was just looking at natural language database queries.
https://dev.to/ngonidzashe/speak-your-q ... tabase-p62
https://dev.to/ngonidzashe/speak-your-q ... tabase-p62
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 931
- Joined: Thu Nov 13, 2008 6:48 am
- Location: London, UK
Re: How to distinguish between label and fields
Hi Mark,mwieder wrote: ↑Tue May 02, 2023 7:46 pmHah! I was just looking at natural language database queries.
https://dev.to/ngonidzashe/speak-your-q ... tabase-p62
I would agree with you but the assumptions here are quite remarkable...
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.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.
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
macOS 12.6.5 (Monterey), Xcode 14.2, LC 10.0.0, iOS 15.6.1
Targets: Mac, iOS
Targets: Mac, iOS