Lock a table field

[bn]

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

[jacque]

Again, I was just trying to ferret whatever sort of message that made that ghost field pop up.

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.

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.

[bn]

Hi Jacque,

this code from above works in LC9 DP9

Hi Craig,

you could try on a tableField which happens to be field 3 in my case

Code: 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

or

Code: 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

The handler is in revIDELibrary

Then you can fiddle with traversalOn etc

Also there is a frontScript "revTableLibrary" in LC9 DP9

Kind regards

Bernd

[jacque]

Thanks Bernd. I forgot to switch on the settings to show IDE scripts in lists.

[bwmilby]

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:

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))

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.

[bogs]

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".

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

[dunbarx]

Told you I liked Bogs' style.

Craig

[bogs]

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.

[bwmilby]

This should work though:

Capture.JPG (20.71 KiB) Viewed 7284 times

@bogs... the property set exists, but in 6.x it is just hidden from normal person access

[bogs]

(Working my way up to 'normal' person level ) I was able to look at those sets using

Code: Select all

put the customPropertySets of field 1 into field "Field" 
// table field into regular field...
 

in 6.5.2 it lists

• cREVTable
  cREVGeneral

I am pretty sure (though no time today) that it isn't going to be that much more difficult to list all the props of those sets.

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
-----------------------------

[bogs]

This should work though:

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 !!

[bwmilby]

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).

[bogs]

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 -

cRevTable
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

Which I am sure is old news to anyone that has been doing this a gazillion years, but is 'new' news for me

[bwmilby]

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).

[bogs]

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.