RE: Reassigning Tab key

[DaveUK]

I have a document which is protected as read only, except for allowing text boxes to be editable.
What i would like to do is to make the TAB key select the next editable region instead of Tabulating inside the text box itself.
Is this possible?
And if so please could someone help me with some code !

TIA

[lucas]

Dave,
I may be out of line here but this seems like the hard way to do things in Word. Why not use a userform for the data entry directly to bookmarks. All can be protected so they can't change anything except what you allow on the userform.....textboxes are......not great for data entry(I think)

[fumei]

Textboxes can be useful for data entry. The user sees the entry immediately (no commanbutton action required), and they can re-edit immediately if needed (no need to reload the userform).

That being said, I have to agree with Steve. Overall, userforms are better IMO. If it is four or five data entry points, sure, formfield textboxes can work fine. But if there is any logic required, any validation of the user input, if is (IMO) better to use a userform.

Dave, there is some inconcsistency here. On one hand you say:
which is protected as read only, except for allowing text boxes to be editable.
which clearly states nothing is editable except for textboxes.

On the other hand, you say:
select the next editable region instead of Tabulating inside the text box itself"next editable region"???

If you are only allowing edits in the textboxes...what is the next editable region?

In any case, yes, it is possible to reassign the Tab key. For example:Sub ChangeTab()
' clear Tab command from active document

CustomizationContext = ActiveDocument
FindKey(BuildKeyCode(Arg1:=wdKeyTab)).Clear

' build new Tab command for document
CustomizationContext = ActiveDocument
KeyBindings.Add KeyCode:=BuildKeyCode(Arg1:=wdKeyTab), _
KeyCategory:=wdKeyCategoryCommand, _
Command:="WhateverYouWant"

End Sub


Sub WhateverYouWant()
MsgBox "Yadda yadda...no Tab here."
End SubExecuting ChangeTab will change what happens when you use Tab. For the active document. People normally use BuildKeyCode on templates, as in:CustomizationContext = NormalTemplate

' OR

CustomizationContext = AttachedTemplateBut you certainly can use it for a single document.

Once ChangeTab has fired, using Tab will fire the procedure assigned to Tab - in this case a message box.

HOWEVER! Even reassigning the Tab this way will NOT, repeat: will not, change using Tab when the document is protected for forms.

Execute ChangeTab, press Tab...message is displayed.

Protect for forms, press Tab...the next formfield is selected as normal.

Unprotect it, press Tab...message is displayed.

Tab as the selecting movement between formfields is built deep into Word, and can not be altered (as far as I know). That function is not accessible ("exposed") to VBA.

But back to WHY. Why do you want to do this, and please clarify exactly what it is you want to do. I am not exactly sure what you are trying to do.

[DaveUK]

Many thanks for your replies and the help they contained.

I have decided on, as was mentioned, editing text boxes but without changing any function of the tab key.

I guess it is because i am more experienced with Excel and i need to learn a lot more about the word object model.

Thanks again

[fumei]

Ah, the Word Object Model. I highly recommend you do that. It is the only way to really get a handle on what is going on. I have to warn you though...at times it seems like a very Alice-in-Wonderland place. It can make the Excel Object Model seem like the paragon of sanity.

In many ways it is a beautiful and bizarre model. A lot depends on understanding what Microsoft conceives as the document model. What they think a "document" is.

Just as an example:

You have a document with three Sections, each with its own header text.

Section 1 - "Section 1 yadda text"
Section 2 - "Section 2 yadda text"
Section 3 - "Section 3 yadda text"

The document is saved - that is the way it IS.

You delete the Section break between Section 2 and Section 3 as you decided that Section 2 and Section 3 should be merged.

Then you decide, oh, what the heck, it really is one Section anyway. You delete the Section break between Section 1, and Section 2.

Intuitively - as least I think so - if Section 2 has "Section 2", and Section 3 has "Section 3", if you delete the break, the separation between them, the preceding value should remain. That is, Section is still Section 2. Section 3 is gone, and is now contained in Section 2. Right?

Nope. Section 2 will take the values of Section 3 header.

And if you delete all the Section breaks, so it is now just Section 1, the header would be..."Section 3 yadda text".

It has been this way from the earliest versions of Word. Word's document model (not Object Model) envisions a document as being whatever was LAST.

So in the case described, Word retains the LAST values for the header text and moves it backwards as you delete the breaks. Personally I find this strange, but that is how Microsoft see what a document should do.

Have fun!