Tabbing in InfoPath with TAB

S

StefanO-nl

Using the TAB-key it's possible to go from one TextBox to another. This
almost works fine: the text in the textbox is selected and typing a new text
erases the text already present in the textbox. However, sometimes the text
is not selected and the cursor is set at the first position of the textbox.
So when a user now tabs into this textbox he first must delete the contents
of the textbox, before (or after) typing new text.
I've looked for several things that might could have something to do with
this, but I didn't find anything. I thought it might have something to do
with an event or a condition or something like that... Any ideas or is this a
known issue?

Thanks!
 
A

Andrew Watt [MVP - InfoPath]

Stefan,

Can you be precise about a situation or situations that produce this
behaviour consistently for you?

Or is it inconsistent? Are you saying that you can tab through a form
and it selects all most of the time but if, a little later, you again
tab through that form that a different behaviour is seen?

I don't recall seeing it and using TAB or Shift-TAB just now across a
range of controls it doesn't happen for me.

Andrew Watt
MVP - InfoPath
 
S

StefanO-nl

The textboxes with this behaviour are (each time) the same. Most of the other
textboxes select the whole text, so if you type after pressing the Tab-key,
the text will be erased.

I couldn't figure out why those textboxes have that behaviour; that's why I
posted here... :)

I'm using InfoPath SP1 with C# btw.
 
A

Andrew Watt [MVP - InfoPath]

OK, so it's reproducible on specific text boxes. That removes one
possible interpretation of your post. :)

So ... can you describe your settings for the text box(es) where you
see the undesired behaviour? Have you, for example, set up Data
Validation or Rules on the text box that doesn't behave as you want?

My guess is that it is something you have set or coded for the text
boxes. But, to be honest, I can't think of what that might be at the
moment. :)

If you figure out the cause please let us know.

Andrew Watt
MVP - InfoPath
 
S

StefanO-nl

It's not only reproducible on specific text boxes, but I couldn't find
anything different with those text boxes (compared to the text boxes with the
normal behaviour). I removed events and conditional formatting on those text
boxes, but my guess is an event, conditional formatting or even the use of
the underlying datasource in *another* textbox (or datafield) is causing the
problem...

I was hoping this problem sounded familiar, but if I understand you
correctly, I first must identify the exact problem, before you know the
solution? My guess is that if I finally have found the problem, the solution
is simple or maybe the solution is the problem... ;-)
 
A

Andrew Watt [MVP - InfoPath]

It's not only reproducible on specific text boxes, but I couldn't find
anything different with those text boxes (compared to the text boxes with the
normal behaviour). I removed events and conditional formatting on those text
boxes, but my guess is an event, conditional formatting or even the use of
the underlying datasource in *another* textbox (or datafield) is causing the
problem...

I was hoping this problem sounded familiar, but if I understand you
correctly, I first must identify the exact problem, before you know the
solution? My guess is that if I finally have found the problem, the solution
is simple or maybe the solution is the problem... ;-)

The other alternative is to email me a copy of the form template with
the problem. I am happy to poke around in it and see if I can see
anything that sheds light on the situation.

Andrew Watt
MVP - InfoPath
 
A

Andrew Watt [MVP - InfoPath]

I am posting this after spending a little time with the form.

I can reproduce the undesired behaviour on the text boxes. They are
set to Euros Dutch currency. Setting the format to number stops the
problem. Changing it back to Euros Dutch brings the problem back
again.

However ... creating a simple form using Euros Dutch doesn't exhibit
the problem.

In the troublesome form the undesired behaviour only seems to occur
when the control being tabbed out of has had its value changed. This
is true with TAB and Shift+TAB on my testing so far.

Does this behaviour ring a bell for anyone?

Andrew Watt
MVP - InfoPath
 
B

Brian Teutsch [MSFT]

I've never heard of any issues with a specific type of data formatting
interfering with tabbing through controls. The description that sometimes
tabbing out fails sounds more like what could happen if the same field is
located in multiple places on the form. Perhaps changing the currency format
to be different in the two controls is causing the issue.

Brian
 
S

StefanO-nl

The same field isn't located in multiple places on the form, i.e. it isn't
used multiple times as an textbox (or other type of input field). It is
however used in calculations and conditional formatting.

I've you like I could send you the form, so you can look at it as well?
 
A

Andrew Watt [MVP - InfoPath]

Hi Brian,

Stefan sent me the form yesterday and we have worked on trying to
narrow down the problem together. It's reproducible and it somehow
depends on the validity or otherwise of data in one or more other form
controls.

You can use Tab and Shift+Tab to move around ok. That's not the
problem.

It's how the data displays in the form control that is tabbed
(successfully) to that is inconsistent. Sometimes all the content is
selected in the form control which is tabbed to. Sometimes it isn't
selected and the cursor sits before the first character in the
control.

The inconsistency of behaviour is a niggling problem.

You mention a field possibly being duplicated, but that doesn't fit as
far as I can see. First, there are no warning icons which would be the
case with duplicated binding, I think. Second, changing the display
format doesn't change the data binding, does it? Or am I missing
something in your answer?

Andrew Watt
MVP - InfoPath
 
B

Brian Teutsch [MSFT]

I would be curious to see the form. I can't think of good explanations as to
why you're seeing the strange selection behavior.

Brian
 
Top