Opened 11 years ago

Closed 11 years ago

#3971 closed enhancement (fixed)

Patch: enable mixed mouse+keyboard input in Sudoku

Reported by: Stef Owned by: axeld
Priority: normal Milestone: R1
Component: Applications/Sudoku Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Platform: All


Currently, Sudoku supports either mouse input (point at cell, click to insert numbers) or keyboard input (arrow keys select cell, type numbers to insert them). When attempting to combine the two (point to select cells, type a number to insert it) weird things happen.

The first keypress selects the cell under the mouse cursor (blue outline). The second keypress inserts the number in this cell. However, when forcing a repaint (drag the window off the screen and back), it can be seen that the first keypress inserts the number at the previous keyboard position without updating the screen.

The attached patch does not address the repaint issue directly. Instead, it always sets the keyboard input position to the mouse input position (if valid). Not only does this solve this issue, it also enables mixed input as described above (point and type).

Attachments (1)

sudoku.patch (524 bytes ) - added by Stef 11 years ago.
patch for SudokuView.cpp (against hrev30866)

Download all attachments as: .zip

Change History (4)

by Stef, 11 years ago

Attachment: sudoku.patch added

patch for SudokuView.cpp (against hrev30866)

comment:1 by stippi, 11 years ago

Resolution: fixed
Status: newclosed

Applied in hrev30918. Thanks a lot!

comment:2 by Stef, 11 years ago

Resolution: fixed
Status: closedreopened

Thanks, but the modified patch applied in hrev30918 still fails when _GetFieldFor returns true but one of the other clauses in the if statement on lines 850-852 passes. This can be seen for instance when there is a number in the cell pointed to by the mouse; it is not possible to change this number with the point-and-type method, as any numbers typed appear in the previous empty cell pointed to.

Moving the assignments above the if statement (but obviously after the _GetFieldFor call) as in my original patch allows numbers to be changed without such unexpected behavior.

comment:3 by stippi, 11 years ago

Resolution: fixed
Status: reopenedclosed

Sorry about that! I will try to be more careful next time!

Note: See TracTickets for help on using tickets.