Table field question

[dunbarx]

I have a table field (fld 1) with some text in several tab delimited "cells" and with a few lines. The usual. In the field script:

Code: Select all

on rawkeyUp tkey
   if tkey = 65289 then -- tabKey
      put random(99) && the selectedChunk of fld 1
   end if
   pass rawkeyUp
end rawkeyUp

If I select a "cell" and hit tab, I get the random number, but never anything but empty for the selectedChunk. Neither for the selectedLine nor selectedText.

The tabKey message is not sent from table fields if there is a selection in that field. This is, I assume to allow the selection to pass to the next "cell", instead of the next field in tab order.

This all started in a thread where the OP wanted to know, when tabbing through a table field, when he had reached the last "cell" with data in it. No problem. Just find the number of items from the beginning of the line to word 2 of the selectedChunk. Since tabKey is not set when there is a selection in a table field, I tried the rawKeyUp message, which is indeed sent, but then cannot then get the selectedChunk.

There is indeed a selectedChunk, since if I put this into a button script:

Code: Select all

on mouseUp
   set the itemdel to tab
   select item 2 of line 2 of fld 1
   get word 2 of the selectedChunk of fld 1 
   answer the number of items of char 1 to it of fld 1 
end mouseUp

That works fine, and would be the pathway to the OP's issue. What am I missing?

Craig Newman

[SparkOut]

When typing normally and you have a selection, then press a key, is it not expected that the "typed value" will replace the current selection?
So in a plain text field, what in essence I would expect, is to have the selectedChunk deleted and replaced with a tab, which if translated to a table field might change the layout of cell content as well as the text content.
On Windows 7, LC 7.0.5 if the table object has cell editing enabled, tab key does not edit the text but will move the cursor to the next cell. If the new cell is then edited, the new contents are appended to the previous cell, since no "tab" separator has been inserted, it was just the rendering of the "cell editing" view that changed.
If the cell editing option is turned off, tabbing in the table does indeed have the effect I mentioned at first. The selection is replaced with a tab, moving the cell contents around as well as replacing the selection. The selectedChunk shows a negative value (eg char 27 to 26 of field 1).

[dunbarx]

Sparkout.

Certainly if cell editing is turned off, hitting tab will append a tab character after the selection, and as you rightly pointed out, the text in that line moves over one "cell".

But I am still wondering why I cannot get any info about the selectedText. You said:

On Windows 7, LC 7.0.5 if the table object has cell editing enabled, tab key does not edit the text but will move the cursor to the next cell. If the new cell is then edited, the new contents are appended to the previous cell, since

I am in 6.7. If cell editing is enabled, tabbing indeed moves the selection into the next cell, but any editing that takes place occurs only within that newly selected cell. It does not append to the previous cell.; the tab character that separates those two cell stays intact. So there is some internal processing going on in that field, based on the properties that make it a table field in the first place, that determines how it acts.

My question then is this: are there two ways that a table field "displays" selected text? One way being that if one enters a cell via the tab key (which hilites the text in the target cell), that does not mean that the selectedText (or selected-anything) property has been set to that hilited data. But if the data in that cell is selected under script control, as per that button handler, it does?

I still think I am missing something, that what I just wrote is not possibly correct.

Craig

[SparkOut]

I am in 6.7. If cell editing is enabled, tabbing indeed moves the selection into the next cell, but any editing that takes place occurs only within that newly selected cell. It does not append to the previous cell.; the tab character that separates those two cell stays intact. So there is some internal processing going on in that field, based on the properties that make it a table field in the first place, that determines how it acts.

I should have said starting from an empty table. Put the cursor in cell 1. Add a char. Tab to the next cell. Add a char. Tab to the next cell. Cursor is now in cell 3 but the two chars are concatenated in cell 1. If the contents of the field have previously included tabs to separate cells, the tabs are left intact and the cell edited cell content will still be separated from the previous cell by the tab. But there is no underlying way to create a tab to separate cell contents if the table content has not already been set by other means. It seems. Try appending a new cell at the end of your content. Or use the mouse to select a cell past the last occupied one.

My question then is this: are there two ways that a table field "displays" selected text? One way being that if one enters a cell via the tab key (which hilites the text in the target cell), that does not mean that the selectedText (or selected-anything) property has been set to that hilited data. But if the data in that cell is selected under script control, as per that button handler, it does?

I think there are two ways that a table field interacts with content, one which traps tab and enter keys with cell editing enabled in order to navigate cells, but does not pass them, leading to the broken content insertion without a tab to separate the content items. The other, without cell editing enabled, is the raw display without navigation, which therefore does not trap tab keys, therefore replacing selected text with the tab content. The replacement therefore changes the selectedChunk, which apparently reads tab as a negative number of chars. Because of unicode in 7?

I still think I am missing something, that what I just wrote is not possibly correct.

Craig

I think you have uncovered something strange and obscure with the table object properties. It's probably because the table options have always been so poor people have avoided using them, especially since datagrids were introduced, and therefore this arcane stuff was not brought into the light.

[dunbarx]

@Sparkout.

I should have said starting from an empty table. Put the cursor in cell 1. Add a char. Tab to the next cell. Add a char. Tab to the next cell. Cursor is now in cell 3 but the two chars are concatenated in cell 1.

Table field for me have never worked the way you describe, and I cannot imagine the LC version matters. I get no concatenation, and would be shocked if I did. The table field contains preloaded tabs throughout, and its internal structure prevents, say, pressing the backspace key in an empty cell from deleting the tab that is "located" there. Conversely, it prevents a new tab from being appended to the cell text, rather a behavior is implemented where the "focus" in moved to the next "cell". The same can be said for the way the return is handled.

Anyway, does your table field act like you describe???

@Scotland.

Are there indeed two flavors of hilited text in a table field, one where the cell was "focussed" by tabbing into it, and the other by direct reference, as in: "select item 2 of line 2..." where the itemDel is tab? I will send a bug report if this is so. It is untoward behavior.

Craig Newman