LiveCode Forums

Based on the thread "Lock a Table Field" in the beginners pane.

I pull a table field and an "ordinary" field from the tool palette. I set H and V grids on the ordinary field, and tabStops to 75. I set both the lockText and the dontWrap on the ordinary field. The two fields now look exactly the same.

By hand, the only difference I can see in the property inspector is that the dontWrap and lockText checkboxes on the table field are disabled, though they are not on the ordinary field. Hmmm.

I then get "the properties" of each field, and compare them line by line. The only difference between the two are their ID's, rects, layers and names. Frankly, I am not surprised.

So why do they act so differently? In other words what invokes the phantom overlying field in the table field to permit user text entry? In yet other words, and this is the only reason I am fooling around with this, what happened to the maxim that all fields are just members of a single LC object class, but with different properties? Did I miss a property (the "tableField" property?

Craig Newman

Hi Craig,

the difference will be the "cRevTable" custom property set.
Obviously the LC checks this one to see if the field is a "table" field or not.


Best

Klaus

Wow, you mean this?

Huh, frankly from the messages I was seeing in the table field, I thought there was more to it, like the dgProp messages, unless they are all rolled into that cRevTable thing ?

Klaus.

There are major differences between the custom props of a table field and a doctored "normal" field. But I still do not understand what happens when you click in a table field. I am obviously not thinking about this correctly, but custom prop differences notwithstanding, there has to be a message sent to the engine, no? Triggered by a mouseClick, I would think.

So maybe it is a change in a property that is caught in a setProp control structure, that creates that field? But then what changes a property, if not a message?

Craig

Hi Craig,

I think this is a LC front- or backscript which decides to kick in the "revTableLibrary" when neccessary. You can check all the LC "rev..." stacks, and behaviours if you have a free minute (probably day ).


Best

Klaus

Hi Craig,

I tried to explain this in

http://forums.livecode.com/viewtopic.ph ... ad#p159362

it was a mid-air collision between your post here and my post there.

What triggers LC to know it is a tableField is in the frontscript library the "openField" handler. This handler checks if the field has the cRevTable properties set and acts accordingly.

And because it is a frontScript revTable can also determine where you clicked and pop up a temporary field for data entry which is then inserted in the right column and row of the tableField, filling up missing tabs up to the insertion.

Kind regards
Bernd

The "cellEdit" key in the cRevTable property set is what is read by the front script. In 9DP9 you can manually edit the key or use the setting in the PI on the table tab. In the revTableLibrary (front script), there is a handler for mouseUp that kicks off the field creation.

(I just read the library stack that was mentioned earlier, thanks to all that mentioned where to look)

Thanks,
Brian

All.

Thank you for all the replies on both threads.

At what I will call my newbie level of thinking, in the attempt to disable editing, I tried to trap whichever message told LC to create the phantom field. Why I did that is another story.

I opened the message watcher, enabled IDE messages, and logged all messages that were generated when clicking in a table field. I then tried to see what message I might trap to stop that from happening. I tried a few of the most promising, like "RevCreateCellField", "revIDEHandlemouseUp", and others. I suspect that these are generated well after any message that starts in the table field. Well and good; I get that.

So unless I misunderstand LC at a very fundamental level, is that admittedly silly effort futile? In other words, is it possible at all to stop the creation of the phantom field by trapping a message generated in the table field itself?

Be gentle with me...

Craig

You may have seen the other thread, which identifies it as a frontscript. Messages will be trapped there before the field ever sees them, so you need to remove the frontscript to stop the behavior. You might think you could add another frontscript to trap the first one, but the order of frontscript execution can change dynamically, and it's a little silly to add another script just to block an existing one.

Jacque.

You may have seen the other thread, which identifies it as a frontscript.

Oh,my. I completely glossed over that. FrontScript. Of course. Did Bogs mention something about windmills?

But at least LC is behaving like LC should.

Thanks again to all.

Craig

dunbarx wrote: ↑

Thu Oct 19, 2017 6:50 pm

Oh,my. I completely glossed over that. FrontScript. Of course. Did Bogs mention something about windmills?

Welcome to my windmill farm, brother !