Lack of keyboard functionality - 2 issues

GoogleCodeExporter commented 9 years ago

What steps will reproduce the problem?
1.  Glossing or Free Translation Mode in AdaptIt 5.1.0
2.  Attempting to enter the number 2 from my keyboard simply does not work
in the glossing or in the free translation mode.  I can get 1 and 3 and
other numbers, but the number 2 does not register.
3.  When in free translation mode, the tab key does not advance to other
buttons (as it did in previous versions of AdaptIt).  For instance, I
cannot tab to the "Next" button, but whenever I press tab, it stays on
"Shorten".

What is the expected output? What do you see instead?
I expect to be able to use the number 2.  It does not work.
I expect to be able to tab to other buttons, as opposed to using the mouse
to select the buttons each time.  The tab key moves the cursor from the
free translation window to the "Shorten" button only.

What version of the product are you using? On what operating system?
I am using AdaptIt 5.1.0 on Vista.

Please provide any additional information below.
I can copy and paste the number 2 from previously loaded adaptations or
from other word-processing programs.  It is not that the number 2 is not
able to be used, just not functioning directly as a result of a single
keystroke.

Original issue reported on code.google.com by kawill...@gmail.com on 20 Aug 2009 at 12:47

GoogleCodeExporter commented 9 years ago

Thanks for the report, I've not checked the Issues for a while, sorry for the 
delay. 
I'll look into this today (18th Sept). Bill Martin has already verified these 
problems are still present in 5.1.4 for Vista or XP, but not in the Linux or 
Mac 
versions. Getting it fixed might be tricky. --Bruce

Original comment by adaptit.bruce@gmail.com on 18 Sep 2009 at 12:45

GoogleCodeExporter commented 9 years ago

Original comment by adaptitbill@gmail.com on 18 Sep 2009 at 1:18

Changed state: Accepted

GoogleCodeExporter commented 9 years ago

I have found that if you have a numeric pad and use NumLk, the 2 is functional.

Original comment by bussa5...@gmail.com on 18 Sep 2009 at 4:43

GoogleCodeExporter commented 9 years ago

Thanks Bob, that workaround will help. Investigations so far suggest that it is 
a 
coding fault on the part of the Adapt It team, but highly obscure. A press of 
the 2 
key is being interpretted by the phrase box, and also the compose bar's edit 
box 
(which is also what free translation mode uses) as an F10 function key press. 
The 
code which produces the error is Microsoft's, but somewhere in Adapt It our 
code is 
causing the Microsoft code to produce a wrong result. Finding the cause is 
turning 
out to be like looking for a needle in a haystack, at least so far. We are 
continuing to work on it. Other development is on hold until we solve this.

Original comment by adaptit.bruce@gmail.com on 19 Sep 2009 at 12:16

GoogleCodeExporter commented 9 years ago

We did not find, in our Adapt It code, a cause for this problem of a 2 keypress 
not 
resulting in a 2 character being entered into the edit box. However, we've come 
up 
with an acceptable hack which restores correct behaviour. The hack won't get 
called 
if the Microsoft Windows code rights itself at some later date, so whether or 
not 
the underlying cause is fixed, the application as far as the user is concerned 
will 
work correctly. The fix will be in the next release - probably to be called 
5.2.0.

Original comment by adaptit.bruce@gmail.com on 20 Sep 2009 at 4:30

GoogleCodeExporter commented 9 years ago

Unfortunately, we were able to make wxWidgets support tabbing through the 
buttons in 
Free Translation mode. The buttons need to be clicked using the mouse or 
trackpad.

Original comment by adaptit.bruce@gmail.com on 21 Sep 2009 at 2:32

eb1 commented 9 years ago

The behavior seems to be better in 6.5.8 / Windows 7, but the second issue reported is not completely fixed:

Numbers 0-9 can be typed into the edit box correctly.
Pressing the Tab key does move focus to most of the buttons in the tab order. HOWEVER, once focus goes to the Remove button it gets stuck there and pressing Tab or Shift+Tab does not move the focus to another control.

adaptitbruce commented 9 years ago

Hi Erik, I've fixed this - issue two. The Remove button was the ONLY button in the bar which had a style flag set, and it was wxTAB_TRAVERSAL . Ironic, that made the Remove button the only button which didn't participate properly in tab traversal. So I removed its style so it was unstyled as were all the others. Recompiled and tested, and now tabbing steps through all the buttons etc. So this issue is done with.

--Bruce

On 21/03/2015 4:00 AM, Erik Brommers wrote:

The behavior seems to be better in 6.5.8 / Windows 7, but the second issue reported is not completely fixed:

Numbers 0-9 can be typed into the edit box correctly.

Pressing the Tab key does move focus to most of the buttons in the tab order. HOWEVER, once focus goes to the Remove button it gets stuck there and pressing Tab or Shift+Tab does not move the focus to another control.

— Reply to this email directly or view it on GitHub https://github.com/adapt-it/adaptit/issues/52#issuecomment-84070557.

adapt-it / adaptit

Lack of keyboard functionality - 2 issues #52