LiveCode Forums.

What is the setting that causes tab in a field to move the cursor to the next field rather than inserting a tab in the field itself?

Hi Preston,

that is the property "autotab"


Best

Klaus

I'm puzzled! Sometimes autoTab seems to work and sometimes it doesn't. When I put

put the autoTab of field myField into msg

I get the expected "true" or "false" and when I change the autoTab with

set the autoTab of field myField to true

the query

put the autoTab of field myField into msg

shows the changed value as one would expect.

Nonetheless, pressing TAB in myField doesn't insert a tab but moves the cursor to the next field whether the autoTab is true or false.
What is frustrating is that this behavior isn't always the case. Sometimes the command seems to work just fine. My question is:

What are the other settings or parameters that could this behavior?

Hi.

The autoTab property is designed to modify the action of "return" or "enter" keystrokes, not "tab" keystrokes.

You can trap the "tabKey" message, or a rawKeyDown message to take control of tab key presses. Experiment, you will soon be OK.

Craig Newman

If I create a mainstack with a field, pressing TAB in that field does nothing. If I do so in the "contents" view of the inspector for that field, the tabKey inserts a tab which is transfered to the field when I press ENTER in the contents field of the inspector. why?

I have a stack with two fields. Pressing TAB in one of them inserts a tab in its text. Pressing TAB in the second field makes the cursor jump to the first field. Why?

I can trap tabKey in a field script but sending tabKey by script behaves just the same as actually pressing the TAB key. No help!

A card with one field would have no other place to go. The focus stays with that field. Note that tab will actually send focus to other objects. For example, if you have a locked field and a button, and the card has this script:

on focusin
put the target
end focusin

You can see that as you tab the button and field appear in msg.

The contents field of the inspector is simply placing the chars you enter into the field. This is normal, and no different than typing anything else in that venue though quite different than typing directly into the field. The inspector is out of the message path, even the message paradigm. It just loads chars. Try typing "5", then a tab, then a "6", then a tab, then a "7". Your field will contain this text directly. If you copy it and paste into excel, the numbers will format into adjacent cells.

If you have no scripts in your fields. nothing like:

on tabKey
put tab after me
end tabKey

Then I am interested in exactly what you have that would do this. To add a tab by typing that char is, er, difficult. It is easy by script:

put "6" & tab & "7" after fld "yourField".

Do not fret. The actions are all logical and lovable. It is almost always a misunderstanding on the part of the programmer. Almost. Anyway, there are many pathways, even though it may seem at first that they act couterintuitively. After a while it all seems normal.

I've tried copying the two fields in question to a new stack and deleting all scripts, buttons etc. The behavior is the same: tab in one field cycles the cursor through other fields, tabbing in the other field inserts a tab into that field's text. There must be a simple answer to this.

I wanted to attach the demo file but I don't know how. I get a message that the extension (.livecode) is not allowed. Grrrrr!

Hi Preston,

change the suffix to ".rev", that will do.


Best

Klaus

Klaus wrote:Hi Preston,

change the suffix to ".rev", that will do.


Best

Klaus

Message upon trying to upload file:
The extension rev is not allowed.

Hi Preston,

hm, then ZIP the stack, that should work (hopefully)


Best

Klaus

This stack, when run on my computer at least, shows the way that tab in one field jumps to another field while tab in the other field inserts a tab in the text.

OK. It's always something. If it's not one thing it's another....

In the "table" pane of the inspector, the top field had tab stops set at 75. The bottom one had none. If you set both fields with either a value or empty, they will act the same. I don't know if this is general knowledge or not.

These are useful when making table fields. Something had to have set this, since a new field has that value set to empty by default.

Craig Newman

Changing the tab value in table fixed the problem. Thank you so much! I don't know how I managed to change that setting. My Momma said there'd be days like this...