Lock a table field
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
-
- VIP Livecode Opensource Backer
- Posts: 4000
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Lock a table field
Craig,
I thought that was made clear: it all happens in the frontScript "revTable", and a couple of custom properties set in the field in "cRevTable" Those custom properties are looked for in the frontScript in on openfield and the frontscript then knows it is a tableField.
Without the frontScript the customProperties in cRevTable are not looked at by any other Livecode section, except for the Properties Inspector.
That is why it is maybe rude to delete the front script, but nothing else is affected. And you can reinsert the frontScript again without affecting anything else, except that your field is a tableField again.
The big advantage of a tableField (editable) is that you click in any cell and it offers you to input text.
Without tableField you would either have to prepopulate the field with tabs for the number of columns and rows you want. tableField does that automatically.
KInd regards
Bernd
I thought that was made clear: it all happens in the frontScript "revTable", and a couple of custom properties set in the field in "cRevTable" Those custom properties are looked for in the frontScript in on openfield and the frontscript then knows it is a tableField.
Without the frontScript the customProperties in cRevTable are not looked at by any other Livecode section, except for the Properties Inspector.
That is why it is maybe rude to delete the front script, but nothing else is affected. And you can reinsert the frontScript again without affecting anything else, except that your field is a tableField again.
The big advantage of a tableField (editable) is that you click in any cell and it offers you to input text.
Without tableField you would either have to prepopulate the field with tabs for the number of columns and rows you want. tableField does that automatically.
KInd regards
Bernd
-
- VIP Livecode Opensource Backer
- Posts: 7233
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Lock a table field
No, I couldn't find it. The two stacks that bn mentioned don't exist in LC 9 which is where I tested. I can only assume it's been moved to the engine now since there are no behaviors or frontscripts involved. That would imply that there is no "ghost field", the outline is drawn by the engine.Again, I was just trying to ferret whatever sort of message that made that ghost field pop up.
I'll see what comes up on the new thread you started. I don't have any LC versions older than 8 installed right now to test on.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 4000
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Lock a table field
Hi Jacque,
this code from above works in LC9 DP9
Kind regards
Bernd
this code from above works in LC9 DP9
Also there is a frontScript "revTableLibrary" in LC9 DP9bn wrote: ↑Mon Oct 16, 2017 8:01 pmHi Craig,
you could try on a tableField which happens to be field 3 in my case
orCode: Select all
-- revIDESetTableProperty pObject, pProperty, pValue -- in revIDELibrary put the long ID of field 3 into tObject put "cellEdit" into tProperty put "false" into tValue revIDESetTableProperty tObject, tProperty, tValue
The handler is in revIDELibraryCode: Select all
-- revIDESetTableProperty pObject, pProperty, pValue -- in revIDELibrary put the long ID of field 3 into tObject put "cellEdit" into tProperty put "true" into tValue revIDESetTableProperty tObject, tProperty, tValue
Then you can fiddle with traversalOn etc
Kind regards
Bernd
-
- VIP Livecode Opensource Backer
- Posts: 7233
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Lock a table field
Thanks Bernd. I forgot to switch on the settings to show IDE scripts in lists.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Lock a table field
If the table is never going to be edited by the user, you could also manually change the value in the Property Inspector. Select the "cRevTable" custom property set and change the "cellEdit" key to "false". I just checked in 9DP9 and when making that change, the phantom field is not created. Probably easier to just uncheck the "Cell Editing" option in the PI on the table tab though. (Had to do it the hard way first )
Here's the start of the code in revTableLibrary that starts the phantom field magic:
Once in the table, navigation keys are handled to move the field and update contents.
Interesting tidbit: there is still code in the library that supports formatted text in the table (dates/numbers). I don't see any way to set the formats in the PI though. I went back to a 6.x version and didn't see anything there either.
Here's the start of the code in revTableLibrary that starts the phantom field magic:
Code: Select all
on mouseUp
if (word 1 of the tool is "browse") and \
(the cREVTable["celledit"] of the long id of the target is true) and \
(the cREVGeneral["table"] of the long id of the target is true) and \
(within(the long id of the target, the clickLoc))
Interesting tidbit: there is still code in the library that supports formatted text in the table (dates/numbers). I don't see any way to set the formats in the PI though. I went back to a 6.x version and didn't see anything there either.
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
Re: Lock a table field
You do have to remember that, when this discussion ah, started, the table field being used was in 6.x.
Since thats a long ways back for you hotrod youngsters the property you mention didn't exist while we were walking up hill both ways to school...
Take heart though, I am positive Jacque will reform him of his evil, wonted, wicked, old IDE ways
-
- VIP Livecode Opensource Backer
- Posts: 9660
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Lock a table field
Told you I liked Bogs' style.
Craig
Craig
Re: Lock a table field
The amount of things I've learned from Craig, on and off board, add a lot of spice to my life. Someday, I hope to become proficient enough to answer confidently on a wide ranging set of questions, instead of guessing my way through.
Re: Lock a table field
This should work though:
@bogs... the property set exists, but in 6.x it is just hidden from normal person access Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
Re: Lock a table field
(Working my way up to 'normal' person level ) I was able to look at those sets using
in 6.5.2 it lists
I wonder how long till I feel 'sneaky'
*Edit - Learned a new statement, keys()
To reveal the hidden values using your 'super wonky decoder ring', you just need to a. get the customPropertySets, then list the keys. Boy now I feel dumb.
This look right?
-----------------------------
cRevTable
celledit
~~~~~~~~~~~~~~
cRevGeneral
table
revUniqueID
-----------------------------
Code: Select all
put the customPropertySets of field 1 into field "Field"
// table field into regular field...
- cREVTable
cREVGeneral
I wonder how long till I feel 'sneaky'
*Edit - Learned a new statement, keys()
To reveal the hidden values using your 'super wonky decoder ring', you just need to a. get the customPropertySets, then list the keys. Boy now I feel dumb.
This look right?
-----------------------------
cRevTable
celledit
~~~~~~~~~~~~~~
cRevGeneral
table
revUniqueID
-----------------------------
Re: Lock a table field
It should, but apparently does not, whether or not basic table object was selected.
** Edit - My bad, I think I just did not understand what you were shooting for with that picture, it *DOES* work in 6.x with the following set
It is making sure the max editable column is '0' [doh].
Craig, we found the missing link ! COME BACK TO THE DARK SIDE BROTHER !!
Re: Lock a table field
Oops... my image was the setting that allows editing, unchecking it prevents the field from being created. Your way also is elegant (and useful in it’s own right).
Thinking more this morning, I wonder if it could be coaxed into creating a proper mobile field... (I know that is can, just need to see if it is worth the effort).
Thinking more this morning, I wonder if it could be coaxed into creating a proper mobile field... (I know that is can, just need to see if it is worth the effort).
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
Re: Lock a table field
Oh, then I'll take it I did actually interpret your image correctly. That being the case, the 6.x series I am so fond of really doesn't work that way, perhaps they corrected it in the higher levels? I am sure that is the way it is *supposed* to work.
In that first picture, I alternately checked / unchecked cell editing, and then basic table field, however neither had an impact on whether the table could receive focus/text. Unchecking cell editing removed the 'cell', but still allowed the user to enter text (go figure). Tabbing brings you to the next text entry, but still shows no cell.
Unchecking basic table object likewise had no effect. When I finally put '0' as the maximum editable column however, that *did* indeed eliminate the ability to enter text.
On a side note, my little property watcher part of the program filled in a HELLA lot of blanks. The new entries that showed up for keys from the custom property sets keys are as follows -
In that first picture, I alternately checked / unchecked cell editing, and then basic table field, however neither had an impact on whether the table could receive focus/text. Unchecking cell editing removed the 'cell', but still allowed the user to enter text (go figure). Tabbing brings you to the next text entry, but still shows no cell.
Unchecking basic table object likewise had no effect. When I finally put '0' as the maximum editable column however, that *did* indeed eliminate the ability to enter text.
On a side note, my little property watcher part of the program filled in a HELLA lot of blanks. The new entries that showed up for keys from the custom property sets keys are as follows -
Which I am sure is old news to anyone that has been doing this a gazillion years, but is 'new' news for mecRevTable
topcellloc / leftcellloc / formattedview / currentxmouseloc / currenthscroll / bottomcellloc / currentymouseloc / rightcellloc / scrollbarwidth / cellyspacing / rightfieldloc / maxColumnCount / topfieldloc / leftfieldloc / cellxspacing / currentview / currentvscroll / viewablerows / currentxcell / currentycell / currentcellvalue / viewablecolumns / numbertabstops / celledit / bottomfieldloc
~~~~~~~~~~~~~~
cRevGeneral
table / revUniqueID
Re: Lock a table field
I'm looking again to check what I saw yesterday. I'm using 6.7.11 to test.
In "Basic Properties", Lock text is checked and/or Focusable is unchecked.
In "Table", Basic Table object is checked, Cell editing is unchecked.
When I move to browse mode, then I can't interact with the table.
When "cell editing" is enabled, the "lock text" option is checked but is disabled (which makes sense because of the script). When "cell editing" is disabled, then the lock text can be checked.
To be honest, I actually believe that not observing the "focusable" check box/property is probably a bug. If others agree, I'll submit a bug report for not observing the "focusable" property and also PR (it is a one line fix).
In "Basic Properties", Lock text is checked and/or Focusable is unchecked.
In "Table", Basic Table object is checked, Cell editing is unchecked.
When I move to browse mode, then I can't interact with the table.
When "cell editing" is enabled, the "lock text" option is checked but is disabled (which makes sense because of the script). When "cell editing" is disabled, then the lock text can be checked.
To be honest, I actually believe that not observing the "focusable" check box/property is probably a bug. If others agree, I'll submit a bug report for not observing the "focusable" property and also PR (it is a one line fix).
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
Re: Lock a table field
Your re-test made me re-test (using 6.5.2 myself) and the results of the re-test makes me think I must have missed something on the basic page in the previous post. Apparently I did (although I just woke up, so this may be wonky too).
Initially, I left the lockText value alone (IDE checked or unchecked based on options set), as you noted with cell editing on, it is grayed out in the properties (makes sense), but the table is still focusable and able to be typed in. Now for the fun part, I went back to the basic properties to take a look.
I found lockText unchecked (?!) I left it that way, unchecked Focusable and, as you point out am not able to edit the table or even focus on it.
At this point, I thought maybe lockText had no meaning for the table in 6.5.2 So, thinking that might be a 6.5.2 thang, I moved the test to 6.7.9. Focusable and celledit regardless of lockText setting checked or not, same as before. Went to 7.1.4., same thing. Ok, I have a dull life.
Still in 7.1.4, I turned focusable back on, and then checked lockText, surprise, still unable to edit the table. I went back to 6.5.2 and that is the same, I skipped 6.7.9 on the return trip (ok, I'm pretty lazy too) 8.1.6 *did* work a bit differently, in that lockText HAS to be checked, no matter what.
So the result I come up with is that in the 6.x - 7.x series, unchecking cellEditing and then setting either lockText or focusable correctly will prevent editing by the user, but lockText for sure isn't working the way I would think it should. I'm not sure 8 works exactly correctly either, but will defer to someone that uses it a LOT more than I.
Initially, I left the lockText value alone (IDE checked or unchecked based on options set), as you noted with cell editing on, it is grayed out in the properties (makes sense), but the table is still focusable and able to be typed in. Now for the fun part, I went back to the basic properties to take a look.
I found lockText unchecked (?!) I left it that way, unchecked Focusable and, as you point out am not able to edit the table or even focus on it.
At this point, I thought maybe lockText had no meaning for the table in 6.5.2 So, thinking that might be a 6.5.2 thang, I moved the test to 6.7.9. Focusable and celledit regardless of lockText setting checked or not, same as before. Went to 7.1.4., same thing. Ok, I have a dull life.
Still in 7.1.4, I turned focusable back on, and then checked lockText, surprise, still unable to edit the table. I went back to 6.5.2 and that is the same, I skipped 6.7.9 on the return trip (ok, I'm pretty lazy too) 8.1.6 *did* work a bit differently, in that lockText HAS to be checked, no matter what.
So the result I come up with is that in the 6.x - 7.x series, unchecking cellEditing and then setting either lockText or focusable correctly will prevent editing by the user, but lockText for sure isn't working the way I would think it should. I'm not sure 8 works exactly correctly either, but will defer to someone that uses it a LOT more than I.