Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

In what scenario would consume() restore default behavior?  RSS feed

 
Tom Landry
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tried creating a simple sample but all works as expected.

The following code prevents the cursor from moving when inside a cell of a JTable.



When editing a cell, the existing code would use the right/left cursor keys to move from cell to cell as opposed to from character to character when editing a cell.

I planned to override the functionality by tossing in the above code as a test to see if it stops the functionality before I override it.
After placing in the above code, the above functionality no longer occurs, but now the cursor moves within the cell as I wanted which is to move from character to character instead of cell to cell.
Its great it works, but it really shouldn't. Essentially the default behavior has been restored when it should have really disabled the left/right keys.
I assume there is some underlying class someplace that is doing something to affect the behavior.

Since a sample can't be provided I am wondering in what scenarios would the e.consume() restore default functionality?
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
but now the cursor moves within the cell as I wanted


I don't understand that comment since that is the default behaviour without any custom code. Post your SSCCE that demonstrates your test conditions.

To under how Swing handles KeyStrokes you need to understand How to Use Key Bindings. All Swing components bind KeyStrokes to Actions. For example lets take a look at the RIGHT key stroke. The default behaviour when focus is on a JTextField is you move the caret one character to the right. When focus is on a cell in a JTable the cell to the right will become focusable.

Take a look at Key Bindiings for a program that you can download to list all the key bindings for a given component.

When you consume the KeyEvent you effectively disable the key binding for that component which basically means nothing will happen because the component will no longer recognize the KeyStroke so there is no Actiojn to invoke.
 
Tom Landry
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The default behavior when in edit is that the left/right arrows moves the cursor to the next character.

As originally mentioned, when in edit mode the left/right keys would move to the next cell as opposed to the next character.

Adding the code listed above should have essentially disabled the left/right keys but instead has now caused the default behavior to occur instead of disabling.

Also as mentioned above, the only SSCCE available is the scenario is which it works as expected. Unable to replicate the issue with a smaller testcase.
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As originally mentioned, when in edit mode the left/right keys would move to the next cell as opposed to the next character.


Not true!!! The default behaviour is to move to the previous/next character.

Post your SSCCE that demonstrates this behaviour.
 
Hauke Ingmar Schmidt
Rancher
Posts: 436
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think it is a better idea to convert the code to using key bindings first and remove any low level event handling before starting to debug.
 
Tom Landry
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Camick wrote:
As originally mentioned, when in edit mode the left/right keys would move to the next cell as opposed to the next character.


Not true!!! The default behaviour is to move to the previous/next character.

Post your SSCCE that demonstrates this behaviour.


I never said moving to the next cell (in edit mode) was the default behavior but rather what the software was doing.

In any case we seem to be going in circles.

All I was simply asking is in what scenario would this unusual behavior be seen as it can't be replicated with a simplified sample.
 
Rob Camick
Ranch Hand
Posts: 2800
15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
was the default behavior but rather what the software was doing.


So post the SSCCE of your software that demonstrates the behaviour you are trying to describe.

If we see the code then maybe we can explain what is happening (as I have already tried to do).
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!