Single field object class?

Anything beyond the basics in using the LiveCode language. Share your handlers, functions and magic here.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller, robinmiller

Post Reply
dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4927
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Single field object class?

Post by dunbarx » Wed Oct 18, 2017 7:25 pm

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

Klaus
Posts: 9589
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: Single field object class?

Post by Klaus » Wed Oct 18, 2017 8:08 pm

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

bogs
Posts: 606
Joined: Sat Feb 25, 2017 10:45 pm

Re: Single field object class?

Post by bogs » Wed Oct 18, 2017 8:43 pm

Wow, you mean this?
Image
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 ?
ImageImage

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4927
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Single field object class?

Post by dunbarx » Wed Oct 18, 2017 9:45 pm

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

Klaus
Posts: 9589
Joined: Sat Apr 08, 2006 8:41 am
Location: Germany
Contact:

Re: Single field object class?

Post by Klaus » Wed Oct 18, 2017 10:13 pm

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


Best

Klaus

bn
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3188
Joined: Sun Jan 07, 2007 9:12 pm
Location: Bochum, Germany

Re: Single field object class?

Post by bn » Wed Oct 18, 2017 11:25 pm

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

bwmilby
Posts: 33
Joined: Wed Jun 07, 2017 5:37 am
Contact:

Re: Single field object class?

Post by bwmilby » Thu Oct 19, 2017 6:11 am

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

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4927
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Single field object class?

Post by dunbarx » Thu Oct 19, 2017 2:48 pm

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

jacque
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3932
Joined: Sat Apr 08, 2006 8:31 pm
Location: Minneapolis MN
Contact:

Re: Single field object class?

Post by jacque » Thu Oct 19, 2017 6:11 pm

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.
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com

dunbarx
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 4927
Joined: Wed May 06, 2009 2:28 pm
Location: New York, NY

Re: Single field object class?

Post by dunbarx » Thu Oct 19, 2017 6:50 pm

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

bogs
Posts: 606
Joined: Sat Feb 25, 2017 10:45 pm

Re: Single field object class?

Post by bogs » Thu Oct 19, 2017 8:29 pm

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

Post Reply

Return to “Talking LiveCode”