autoadvance bug or a shortcut key conflict

[Mike Wilson]

I have searched on this and I am now tired!

So I have a state field. When the user types in the state with capital letters, the cursor jumps to the previous field. "HOLY COW" I say. After hours of screwing with this I discover that the issue does not come from the transform to caps field rule or the code that I placed that checks the state value against the cstates("a"+crlf()) list, but comes from the data entry field rule 'auto advance after field filled' being checked. Well, gosh why would that be?? A BUG surely.

NOPE! I figured out that the WINDOWS shortcut key Shift-Tab performes the move to previous field function.....so... the advance field rule in Alpha must just be sending a {TAB} at the time the user has the Shift key pressed to capitalize the state entry. Right?? NOPE! Why do I believe to know this:

IF UPPER(a_user.key.value) = "{+TAB}"
a_user.key.handled = .f. 
msgbox("shift tab pressed")
END IF

would be firing the msgbox if the action of advance was to send a {tab} key while I am pressing the shift key, and it aint. The gray hairs are multiplying!!!

So what is the answer to getting the cursor to advance to the next field after the field value entered has reached the field size limit without using the advance after filling field rule? Or, does anyone know a way to disable the windows shift-tab shortcut key function? An example is attached for playing. Thanks

[Tbaker]

Re: autoadvance bug or a shortcut key conflict

Mike

I see exactly what you have posted.

Here is a workaround

Changed some code in the onwrotfield event for city to

if topparent:state.value !$ cstates("a"+crlf())
	topparent:state.value=""
	topparent:state.activate()
	end
end if

topparent:zip.activate()

This will go to the next field - however, you still see a slight flicker as the focus goes to the first field then to the zip code field.

I tried everything I could think of to trap the shift tab key but could not trap it.

Unless you hear differently from someone else on the board, I would send in a bug report.

Tom

[G Gabriel]

Re: autoadvance bug or a shortcut key conflict

Mike:
I am no where near alpha to test anyth1ing, but just a preliminary question:
what is the tab order of the fields?

[Mike Wilson]

Re: autoadvance bug or a shortcut key conflict

Tom,
Thanks for replying. That added code does get the cursor to advance to the forward field but if the entry does not fulfill a valid state abbreviation, like XX, the state field is blank.

G,
The tab order is City, State, Zip.

I've been at this for many hours, searching the boards and trying work arounds and I'm wasted by it personally. I'm at the point of giving up and having the user "learn" they can' enter a state as caps. I'm spent and goodnight....

[Tim Kiebert]

Re: autoadvance bug or a shortcut key conflict

Mike,

I see the same behaviour here as well in V10/10.5. I also see the same thing in v9 and v8. I think your hypothesis about the shift key being down just as the auto advance kicks in is a good one. No suggestions on how to fix it.

Since you also have an Upper transformation in field rules maybe the users will get used to not needing the shift key.

[Tbaker]

Re: autoadvance bug or a shortcut key conflict

Mike

I cut and pasted the wrong code the last time, here is the code that works

if topparent:state.value !$ cstates("a"+crlf())
	topparent:state.value=""
	topparent:state.activate()
	end
else
	topparent:zip.activate()
end if

Tom Baker