Single field object class?
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Single field object class?
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
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
Re: Single field object class?
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
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
Re: Single field object class?
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 ?
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 ?
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Single field object class?
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
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
Re: Single field object class?
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
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
-
- VIP Livecode Opensource Backer
- Posts: 4003
- Joined: Sun Jan 07, 2007 9:12 pm
- Location: Bochum, Germany
Re: Single field object class?
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
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
Re: Single field object class?
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
(I just read the library stack that was mentioned earlier, thanks to all that mentioned where to look)
Thanks,
Brian
Brian Milby
Script Tracker https://github.com/bwmilby/scriptTracker
Script Tracker https://github.com/bwmilby/scriptTracker
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Single field object class?
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
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
-
- VIP Livecode Opensource Backer
- Posts: 7237
- Joined: Sat Apr 08, 2006 8:31 pm
- Location: Minneapolis MN
- Contact:
Re: Single field object class?
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
HyperActive Software | http://www.hyperactivesw.com
-
- VIP Livecode Opensource Backer
- Posts: 9669
- Joined: Wed May 06, 2009 2:28 pm
- Location: New York, NY
Re: Single field object class?
Jacque.
But at least LC is behaving like LC should.
Thanks again to all.
Craig
Oh,my. I completely glossed over that. FrontScript. Of course. Did Bogs mention something about windmills?You may have seen the other thread, which identifies it as a frontscript.
But at least LC is behaving like LC should.
Thanks again to all.
Craig