Generally speaking there is no key 12. Twelve is created by key 1 + key 2, which is two keystrokes. On those keypads I've seen which have keys beyond 0-9 which are only one keystroke, they generally use a special non-numeric character to represent that key internally. That is all a function of how the keypad manufacturer has it set up.
Just as a passing comment, your example makes no sense to me whatsoever.
Without seeing all the code it's difficult to give a good answer, but can't you put that statement after the code that displays the character? If not, then use a variable to keep track of the last character displayed and change the code to
IF previousKey = 12 THEN DEBUG CR
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
Based only on what I think you're trying to say, the answer should be fairly obvious. If 11=B then 12=C, as that's the only logical sequence from there. Is this a telephone style keypad (keys labelled 0-9,·* and #)?
I can't believe the keypad doesn't have a data sheet available? That would answer all of these questions, and probably more.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Post Edited (Bruce Bates) : 4/3/2006 9:49:48 PM GMT
roberto,
i'm interested by your answer but first you have to had some information like:
wich kind of keypad
wich matrix
did you use a matrix "translator"
when you say "11" i think it's probably in two keystroke, how your program handle and wait for the second keystrooke.
Let know,
Michel
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards from Belgium,
Michel Dechief.
Engineer and professor at university off Brussel(artificial intelligency)
Based on your program, does the keypad look like this:
123A
456B
789C
E0FD
If so. that's rather strange in my experience. If you're looking for the output of the LOOKUP to be one "character" you need to emit HEX codes in the range x0 - xF which will give you 16 values, each in one NIB. I'm guess that was your original question.
No, you have the line "IF key = 11 THEN DEBUG CR" before the debug statement that outputs the key. If it was after the debug statement that outputs the key, the 'B' would be at the end of the line.
If you still can't figure it out, post the code you are currently using and we can show you where to make the change. The code you posted yesterday doesn't correspond to the output in your last post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
again:
gosub keyScan
if press = 0 then again
debug "key pressed = ", hex key,cr
if key = 11 then debug cr 'this is where i made the chage and the output is still the same
press = 0
goto again
doesn't produce this output:
12346
B4545755
B1212454
If you don't show us the actual code and the actual output how are we supposed to help you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
It does matter that you are showing us the code of one program and the output of another program. It's impossible to debug that way. Post the current code and output when you get home and we can fix this in a second.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ OS-X: because making Unix user-friendly was easier than debugging Windows
roberto
Posts: 37
Comments
Generally speaking there is no key 12. Twelve is created by key 1 + key 2, which is two keystrokes. On those keypads I've seen which have keys beyond 0-9 which are only one keystroke, they generally use a special non-numeric character to represent that key internally. That is all a function of how the keypad manufacturer has it set up.
Just as a passing comment, your example makes no sense to me whatsoever.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
Based only on what I think you're trying to say, the answer should be fairly obvious. If 11=B then 12=C, as that's the only logical sequence from there. Is this a telephone style keypad (keys labelled 0-9,·* and #)?
I can't believe the keypad doesn't have a data sheet available? That would answer all of these questions, and probably more.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
Post Edited (Bruce Bates) : 4/3/2006 9:49:48 PM GMT
i'm interested by your answer but first you have to had some information like:
wich kind of keypad
wich matrix
did you use a matrix "translator"
when you say "11" i think it's probably in two keystroke, how your program handle and wait for the second keystrooke.
Let know,
Michel
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Regards from Belgium,
Michel Dechief.
Engineer and professor at university off Brussel(artificial intelligency)
Based on your program, does the keypad look like this:
123A
456B
789C
E0FD
If so. that's rather strange in my experience. If you're looking for the output of the LOOKUP to be one "character" you need to emit HEX codes in the range x0 - xF which will give you 16 values, each in one NIB. I'm guess that was your original question.
lookup key,[noparse][[/noparse]$01,$02,$03,$0A,$04,$05,$06,$0B,$07,$08,$09,$0C,$0D,$00,$0F,$0D],key
Now your positional keys have a value which is commensurate with how they are labelled.
I hope that's what you were after.
Regards,
Bruce Bates
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
<!--StartFragment -->
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
If you still can't figure it out, post the code you are currently using and we can show you where to make the change. The code you posted yesterday doesn't correspond to the output in your last post.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
doesn't produce this output:
If you don't show us the actual code and the actual output how are we supposed to help you?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
OS-X: because making Unix user-friendly was easier than debugging Windows