Strange TAB behavior

Hello all,

I've googled this question with every permutation I can think of and
kind find an answer.

I have created a multipage tabbed form for data entry. The tab behavior
on the first multipage works as expected. Sporadically, on the second
multipage of the form, the TAB behavior changes. As you tab through
the text boxes, the tab key behavior changes from moving you from the
current text to the next textbox in the tab order, to acting as a tab
keydown in a word processor or rich text box... it adds 5 spaces to the
end of the text in the current textbox.

Like I said, it's not a consistent problem. It pops up randomly.
More so on certain user stations, but I don't believe I have a
"versioning" problem.

If I close the form and reopen it, most times it will go back to the
expected behavior, (moving through the textboxes in taborder.) [ I've
got a second button located directly on the sheet that will reopen the
form with current data from the sheet 're-listed(?)' in the
textboxes, but I'm getting a lot of grumbling from the users at work
because of the weird behavior.]

Can anybody tell me what I've done to cause this or is this just a
bug in Excel?

(There's extra information about the form below, if needed, but above
is the basic question.)

Thanks,
Mike Davidson


**Extra Info**

The fom is a multipage form. The second multipage has several
textboxes that have a default value of zero. I did this, because my
math "needs" A value to be entered, and I didn't want null values AND
the data for these fields are not required entries. Theres data
validation for the boxes that checks for null or nonnumeric data. All
math and data validation is tied to the click event of a command button
(btnFinished). The only code tied directly to the textboxes events are
routines that change the backcolor of the textboxes on entry and exit.

After the user completes mulipage2, theres a button that posts the data
to the sheet and does the math. There's also a button on the sheet
itself that reopens the form and pulls the previously entered data back
into the textboxes. The button is on the sheet to allow the user to
correct data that passed validation, but was just "incorrect." I
include this information, because it appears that the proper tab
behavior is restored by cycling through this process. Closing the form
and posting data to the sheet and then reopening the form with current
data.

Hello all (again)

I forgot to add... the tabkeybehavior on the controls is set to
false...
(the most important part and I forgot to put it in... nice...)

Mike Davidson

You don't use setfocus or sendkeys in any of the events. You don't change
the tabindex or tabstop properties. You don't set cancel = false in any of
the exit events.

If all that is true, I would still comment out all the textbox related
events and see if the problem goes away.

--
Regards,
Tom Ogilvy





"m davidson" wrote:

> Hello all (again)
>
> I forgot to add... the tabkeybehavior on the controls is set to
> false...
> (the most important part and I forgot to put it in... nice...)
>
> Mike Davidson
>
>

Tom,

No sendkeys, no changes to tabindex or tabstop, and no cancel = false
for exit events.

BUT, I do have setfocus code related to data validation. But that
code is tied to the click event of a button (btnFinished) and the weird
behavior is happening prior to the button being clicked.

I'll do what you said and comment out the backcolor change code and see
if it goes away. Got any suggestions on providing a visual cue to
users on which control has focus without using backcolor? Can I change
the blinking cursor to something more attention grabbing... maybe a
blinking square?

There is some new information... I am seeing the behavior on some of
the users workstations, but I am having great difficulty re-creating
the error on the the machine I developed it on... well... not great
difficulty, I haven't been able to re-create the error on that
machine. I am also going to redistribute the master copy of the app.
I've scoured the code and can't find any user corruption. I wasn't
supposed to have a versioning problem, but I'll double check... IT said
that everybody should be on the same version.

I am new to this. Frustrating because the "hard part" of the app works
and the "easy part" is whipping me.

Thanks for the reply,
Mike Davidson

The commenting out of the code is just to eliminate that as the source of
the problem for testing/debugging purposes. If the problem still manifests
with that code not running, then the problem is elsewhere. If it does clear
up, then you have identified the cause and you can examine that code and try
to fix it.

You either have run into a systemic bug - which you can't fix and will have
to work around, but I have never seen it cited here, or you code is causing
the problem probably through some unexpected synergistic way. Then you have
to identify that.

The fact that it only happens on some machines, however, would seem to
indicate it isn't your code - but that makes it much tougher to identify the
cause. Then it might be some windows setting in terms of mouse settings or
keypress settings - some users may be holding down the tab key long enought
that it is seen as two key presses.

--
Regards,
Tom Ogilvy



"m davidson" <[email protected]> wrote in message
news:[email protected]...
> Tom,
>
> No sendkeys, no changes to tabindex or tabstop, and no cancel = false
> for exit events.
>
> BUT, I do have setfocus code related to data validation. But that
> code is tied to the click event of a button (btnFinished) and the weird
> behavior is happening prior to the button being clicked.
>
> I'll do what you said and comment out the backcolor change code and see
> if it goes away. Got any suggestions on providing a visual cue to
> users on which control has focus without using backcolor? Can I change
> the blinking cursor to something more attention grabbing... maybe a
> blinking square?
>
> There is some new information... I am seeing the behavior on some of
> the users workstations, but I am having great difficulty re-creating
> the error on the the machine I developed it on... well... not great
> difficulty, I haven't been able to re-create the error on that
> machine. I am also going to redistribute the master copy of the app.
> I've scoured the code and can't find any user corruption. I wasn't
> supposed to have a versioning problem, but I'll double check... IT said
> that everybody should be on the same version.
>
> I am new to this. Frustrating because the "hard part" of the app works
> and the "easy part" is whipping me.
>
> Thanks for the reply,
> Mike Davidson
>