I’m posting all of this so I might learn something from feedback, and
it’s also possible I've found an oddity. Read on…
For simplicity, when I say “tabbed space” I’m referring to the white
space a Tab key generates.
event.keyCode will return the keycode value of the pressed key,
regardless of when you check it.
So, as I said above, I have no trouble knowing when the user hits the
Tab key.
As for selecting (focus) the next edit box, I’m using a simple switch/
case loop to manually specify the next box in line to be selected when
the user hits the tab key.
The problem is a bit lengthy to explain in words, so bear with me.
FYI- I’m currently using the second example. I just posted the first
example to explain what I found.
Let’s say there are three edit boxes, with keyD(); specified on the
onkeydown event.
The box names will be edit1, edit2, edit3.
function keyD() {
var source = event.srcElement;
switch (source.name) {
case "edit1": next = edit2; break;
case "edit2": next = edit3; break;
case "edit3": next = edit1; break;
}
if (event.keyCode == 9) { // 9 is Tab key
next.focus();
next.value = '0';
return;
}
// Key pressed was NOT Tab, do something else
The problem is that when the Tab key is pressed, the “tabbed space”
goes somewhere. If you catch the event on a onkeyup event, the edit
box you leave will have a tabbed space, if you catch the event on a
onkeydown or onkeypress the “tabbed space” will be in the next edit
box you focus on. My example above will create the latter scenario. I
used the next.value = '0'; to try to prevent the tabbed space.
However, the code above has a weird effect. Assume I've specified that
the edit boxes begin with a value of 0. If we are in the edit1 box and
hit the Tab key, the cursor does move to edit2. But the visual result
is
0 tabbed-space blinking-cursor
BUT- (in edit2 where we just landed) if you move the cursor to in
front of the first digit, 0, and then try to move the cursor to the
end of the line (after the tabbed space) the tabbed space is NOT
actually there (the cursor will only go to immediately after the 0).
This is because we set the box value to a Zero with:
next.value = '0';
So even though the tabbed space is not actually there, when you first
land there, the cursor is left at that position and it appears to be
after a tabbed space. It’s an oddity.
I do have a method that works, partially anyway. In my use, the value
in the edit boxes match the value on a progress bar (Three actually,
one for each edit box). As the value in the edit box changes, so does
the value of the progress bar. Since we catch the Tab key event before
the value is sent to the progress bar, I’m using the event onkeydown
keyD(); and this bit:
function keyD() {
var source = event.srcElement;
switch (source.name) {
case "edit1": scroll = progressbar1; next = edit2; break;
case "edit2": scroll = progressbar2; next = edit3; break;
case "edit3": scroll = progressbar3; next = edit1; break;
}
if (event.keyCode == 9) { // 9 is Tab key
next.focus();
source.value = scroll.value; //Eliminates tab space by resetting
value of the box we just left
return;
}
// Key pressed was NOT Tab, send the value to the progress bar, etc.
The above works for my situation, but I still want to better
understand this because if I wasn’t storing the value somehow to rest
the box with, I would be left with still figuring our how to put that
cursor in the right place. Perhaps by counting the string or
something, I just don’t know.
It’s aggravating that something so simple as making the Tab key behave
as the user would expect stumped me like that. Am I going about this
wrong?
TIA
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Desktop Developer Group" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Desktop-Developer?hl=en
-~----------~----~----~----~------~----~------~--~---
