Interaction with Table Fields?

[iGerbil]

Hi,
does anyone know how to detect clicks on cells of a Table Field?
After user clicks on a Table Field, how can I detect on which cell the click happened?

Also, is it possible to retrieve the content of that cell? (I mean directly, instead of getting all data out and then addressing line & item)

One more thing: Table Fields are automatically created groups of individual fields. Is it possible to define custom properties for each of these fields?

[dunbarx]

Hi.

I am going to come back to this reply over the next little while, since there is much discussion about table fields that you need to know.

I like them and use them regularly. But you need to know. You also need to practice.

See:
viewtopic.php?f=7&t=33570&hilit=table

viewtopic.php?f=8&t=33365&p=185554&hili ... ld#p185554

Craig

[Klaus]

Hi iGerbil,

sorry no idea about CELL and its CONTENT, never used that one.
But a TABLE field is NOT a group of fields, just ONE big field and a big
scripted LC library behind it.

A DATAGRID is a group of groups of groups with fields!


Best

Klaus

[dunbarx]

And as Klaus intimated, Datagrids require their own learning curve apart from that of learning LiveCode.

Read, or at least skim, the links I gave. Then come back to see what particular issues you may or may not have. But a table field can do a great deal of work for you if you let it. Know also that a table field is indeed a single field with certain properties set, like tabs delimiting and tabStops formatting the columns of the field. So to answer one question, you can:

Code: Select all

get field "yourTableField"
set the itemDel to tab
put "XYZ" into item 3 of line 4 of it
put it into fld "yourTableField"

or

Code: Select all

set the itemDel to tab
answer item 3 of line 4 of fld "yourTableField"

Craig

[bogs]

1.) does anyone know how to detect clicks on cells of a Table Field?
2.) After user clicks on a Table Field, how can I detect on which cell the click happened?
3.) Also, is it possible to retrieve the content of that cell? (I mean directly, instead of getting all data out and then addressing line & item)
4. Table Fields are automatically created groups of individual fields. Is it possible to define custom properties for each of these fields?

1.) Yes, you have to lock the field and turn transversal off (applies to any field). This allows the field to receive and respond to clicks.
2.) You can use any of a number of ways, in the picture below, I used the mouseText, however you could also use the selectedChunk or any of the similar methods.
3.) Yes, as you can again see in the image below.
4.) A table field, as the others mentioned, is just a field with horizontal / vertical lines drawn on it and some interesting code in back of it. You can create one in code directly within a field, you can limit it's size to only part of a field, you can do many things with it.

Clickity click click...

aPic_TableFieldClicking.png (31.68 KiB) Viewed 6475 times

[dunbarx]

A table field has stuff attached to it. An ephemeral field is created when one clicks in a 'cell", and that field is the one the user enters data into. When that field is terminated, the entry data is placed into the appropriate item in the appropriate line.

You can make a table field from an ordinary field if you set both the "basicTableObject" and "CellEdit" properties, and some others for looks, like the vertical and horizontal lines.

Something in the "CellEdit" property creates that phantom field. It is just the way the tableField is built, sort of a native kluge.

Craig

[bogs]

You can make a table field from an ordinary field if you set both the "basicTableObject" and "CellEdit" properties, and some others for looks, like the vertical and horizontal lines.

Say what ?! I don't remember *that* being a requirement
how-do-i-display-a-table-in-a-field

[dunbarx]

Bogs.

What say?

Making a field just look like a table field is not enough. Without those two properties together, which seem to create the ability to create, place and name the phantom field, you only have an ordinary field with lines in it.

Craig

[bogs]

Making a field just look like a table field is not enough.

I guess that becomes the real question, which the OP would have to answer for themselves. However, for what they are looking to do, the simplified table - in - field (distinction made solely for you, Craig, hee hee) is the most easily accomplished way, as far as I know.

As for the distinction you made, I'm not sure I agree with it, because you are more or less saying "Control X is only that because of two properties, else it becomes Contry Y."

Going by that argument, no control is what it really it, they all boil down to only 1 or 2 sub controls with different properties set, but, saying a button is really a label if you don't have the 3d look property and regular text font doesn't really make sense, does it? If it does, then you might as well just call all the controls by the most primitive control type (I haven't figured that one out, yet, I suspect it is a button heh heh) and drop the rest of it altogether.

It isn't Opaque, it doesn't autoHilite, it doesn't shareHilite, transversal is off, it isn't default.... but it still is a button !

[Klaus]

Making a field just look like a table field is not enough.

Exactly, and there is a library with >3000 lines of script "in use" for the "table field"!

[dunbarx]

Bogs.

Your point that a control is only what its properties are, and is a continuum of those properties to boot.

OK.

But issues with table fields are mainly about the phantom. That to me is a game changer, far more distinctive than say, a field with only vertical lines in contrast with one of both horizontal and vertical lines.

It is what makes a table field a table field, the ability to click on a "cell", derived from that extra library that Klaus mentioned. All else is window dressing. The distinction is arbitrary, I guess, but is the only distinction of distinction.

Craig

[bogs]

I bow to your distinct distinctiveness, my friend