Home » Eclipse Projects » Nebula » How to cancel keyboard event in the Grid?
| |
| Re: How to cancel keyboard event in the Grid? [message #45645 is a reply to message #45436] |
Tue, 08 January 2008 10:15   |
 Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Chris.
Thanks for your answer. The reason why we want this feature is because we
want our underlying model to have complete control of what cell that has the
current focus in the Grid. For instance, when navigating in the Grid we
would like to be able to jump closed cells. Jumping cells in the current
implementation will cause flicker, because the Grid always moves to the
adjacent cell.
We imagine the event flow to be something like the following:
- The focus is in a table cell and the user presses "arrow right".
- The Grid notifies the model about the key press and does nothing more.
- The model interprets the key event and sends an event back to the Grid
telling it that the cell focus has changed.
- The Grid receives the event, reads the current cell from the model and
places the table cursor in the corresponding cell.
With the above design the navigation logic is moved from the Grid down into
the model. It is the model that tells the Grid what to do.
What do you think?
Best regards,
Anders
"Chris Gross" <chris.gross@us.ibm.com> wrote in message
news:flto77$pui$1@build.eclipse.org...
> Hi Anders,
>
> There's no way to prevent the event or its related processing but you can
> listen for the same event and set the cell focus/selection to whatever you
> wish. If this is something that you'd like to see added to the Grid I
> would ask that you explain the business need for a feature like this.
>
> Regards,
> -Chris
>
> Anders Baumann wrote:
>> How can I prevent the Grid from moving the cell focus when the user
>> presses the ARROW keys? I would like to do this, because I want the Grid
>> to ask the underlying model of what to do. I somehow need to cancel the
>> keyboard event, but I don't see how, because the method "onKeyDown" of
>> the Grid is private? Is there any way to cancel the event before it is
>> sent to "onKeyDown"?
>>
>> Thanks in advance,
>> Anders
>>
>>
>>
|
|
| |
| Re: How to cancel keyboard event in the Grid? [message #45704 is a reply to message #45675] |
Tue, 08 January 2008 12:29 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Tom and Chris.
Yes, if we could tell the Grid about "disabled cells" that would solve the
problem with jumping closed cell. But that was just one reason why I wanted
better control of the cell navigation.
Another reason: In our application you are not allowed to move to a new row
if you have dirty data in the current row. When the user tries to move to a
new row, either with the keyboard or the mouse, the application will not
move the table cursor, but instead tell the user that there is uncommitted
data in the current row. This design will cause flicker with the current
Grid implementation, because the Grid will first move the focus to the new
cell and then the model will put it back to the original cell.
Best regards,
Anders
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvj2c$eb9$1@build.eclipse.org...
> Anders Baumann schrieb:
>> Hi Chris.
>>
>> Thanks for your answer. The reason why we want this feature is because we
>> want our underlying model to have complete control of what cell that has
>> the current focus in the Grid. For instance, when navigating in the Grid
>> we would like to be able to jump closed cells. Jumping cells in the
>> current implementation will cause flicker, because the Grid always moves
>> to the adjacent cell.
>>
>> We imagine the event flow to be something like the following:
>>
>> - The focus is in a table cell and the user presses "arrow right".
>> - The Grid notifies the model about the key press and does nothing more.
>> - The model interprets the key event and sends an event back to the Grid
>> telling it that the cell focus has changed.
>> - The Grid receives the event, reads the current cell from the model and
>> places the table cursor in the corresponding cell.
>>
>> With the above design the navigation logic is moved from the Grid down
>> into the model. It is the model that tells the Grid what to do.
>>
>
> Shouldn't it better be moved to a controller? Maybe it would be sufficient
> to teach the Grid how to "disable cells" so they can't receive focus, ...,
> this would be a nice feature people are often requesting for
> SWT-Table/Tree anyways :-)
>
> Tom
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
| | |
| Re: How to cancel keyboard event in the Grid? [message #45792 is a reply to message #45762] |
Tue, 08 January 2008 12:52 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvqun$eha$2@build.eclipse.org...
> Tom Schindl schrieb:
>> Anders Baumann schrieb:
>>> Hi Tom and Chris.
>>>
>>> Yes, if we could tell the Grid about "disabled cells" that would solve
>>> the problem with jumping closed cell. But that was just one reason why I
>>> wanted better control of the cell navigation.
>>> Another reason: In our application you are not allowed to move to a new
>>> row if you have dirty data in the current row. When the user tries to
>>> move to a new row, either with the keyboard or the mouse, the
>>> application will not move the table cursor, but instead tell the user
>>> that there is uncommitted data in the current row. This design will
>>> cause flicker with the current Grid implementation, because the Grid
>>> will first move the focus to the new cell and then the model will put it
>>> back to the original cell.
>>
>> How do you handle the mouse in this situation, you'll also want to cancle
>> the mouse events?
>>
>
> What I wanted to say is that if you could "disable cells" this would solve
> this problem to because when a row is modified you'll have to put all
> cells beside the ones in the currently active row into disabled mode.
>
Yes, we would also cancel mouse events in this situation.
Yes, I guess we could solve the problem by disabling the other rows. But
remember that we still need to notify the model about the event, because we
need to tell the user why the table focus did not move. This could be a
message in the status bar or in an dialog. How would you solve this problem?
One solution could be to still fire a selectionChanged event when the user
moves to a "disabled cell" , but not move the cell focus.
/Anders
> Tom
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
| |
| Re: How to cancel keyboard event in the Grid? [message #45852 is a reply to message #45822] |
Tue, 08 January 2008 14:49 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Tom and Chris.
After thinking about this issue, I have realized that the "disabled cells"
would actually not solve our problem. We need a more flexible solution.
Sorry, but my first description of our application was incomplete. Here is
the correct one:
Two things can happens when a table row contains dirty data and the user
tries to move to another row:
1) The data in the current row is valid: The row is committed to the server
and the table focus is moved to the new row.
2) The data is invalid: The focus stays in the current table cell and a
dialog is shown to the user.
The table focus is moved in case 1, but not in case 2. However, we don't
know if the data is valid before it is sent to the server. This is why we
cannot use the "disabled cells" solution. Instead we would like the Grid to
tell the model about the event, but not move the focus. When the model has
validated the data it should tell the Grid to move the focus or not.
So, we would still like to be able to cancel both keyboard and mouse events
in the Grid. I hope that Chris will add this feature to the Grid. This would
be a great help and give us flexibility to also solve future related
problems.
Alernatively, it should be possible to replace the default keyboard listener
and mouse listener of the Grid. Most users would probably be happy with the
default solution, but it would enable us to implement our own version of
these listeners.
I hope my mail makes sense and thanks for taking the time to answer.
Best regards,
Anders
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvs3t$pqn$1@build.eclipse.org...
>
>>> What I wanted to say is that if you could "disable cells" this would
>>> solve this problem to because when a row is modified you'll have to put
>>> all cells beside the ones in the currently active row into disabled
>>> mode.
>>>
>>
>> Yes, we would also cancel mouse events in this situation.
>> Yes, I guess we could solve the problem by disabling the other rows. But
>> remember that we still need to notify the model about the event, because
>> we need to tell the user why the table focus did not move. This could be
>> a message in the status bar or in an dialog. How would you solve this
>> problem? One solution could be to still fire a selectionChanged event
>> when the user moves to a "disabled cell" , but not move the cell focus.
>>
>
> This is your own task then by adding a keyboard and mouse listener, not
> :-) IMHO it would be a bug if grid would fire an event in this situation.
>
> Tom
>
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
|
| Re: How to cancel keyboard event in the Grid? [message #45948 is a reply to message #45852] |
Tue, 08 January 2008 23:13 |
Chris Gross
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Sounds like you are trying to do something rather atypical. I might
suggest trying to design an alternative UI. As it is now, I don't plan
on adding any features that would support this paradigm.
Regards,
-Chris
Anders Baumann wrote:
> Hi Tom and Chris.
>
> After thinking about this issue, I have realized that the "disabled cells"
> would actually not solve our problem. We need a more flexible solution.
>
> Sorry, but my first description of our application was incomplete. Here is
> the correct one:
>
> Two things can happens when a table row contains dirty data and the user
> tries to move to another row:
> 1) The data in the current row is valid: The row is committed to the server
> and the table focus is moved to the new row.
> 2) The data is invalid: The focus stays in the current table cell and a
> dialog is shown to the user.
>
> The table focus is moved in case 1, but not in case 2. However, we don't
> know if the data is valid before it is sent to the server. This is why we
> cannot use the "disabled cells" solution. Instead we would like the Grid to
> tell the model about the event, but not move the focus. When the model has
> validated the data it should tell the Grid to move the focus or not.
>
> So, we would still like to be able to cancel both keyboard and mouse events
> in the Grid. I hope that Chris will add this feature to the Grid. This would
> be a great help and give us flexibility to also solve future related
> problems.
>
> Alernatively, it should be possible to replace the default keyboard listener
> and mouse listener of the Grid. Most users would probably be happy with the
> default solution, but it would enable us to implement our own version of
> these listeners.
>
> I hope my mail makes sense and thanks for taking the time to answer.
>
> Best regards,
> Anders
>
>
>
>
> "Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
> news:flvs3t$pqn$1@build.eclipse.org...
>>>> What I wanted to say is that if you could "disable cells" this would
>>>> solve this problem to because when a row is modified you'll have to put
>>>> all cells beside the ones in the currently active row into disabled
>>>> mode.
>>>>
>>> Yes, we would also cancel mouse events in this situation.
>>> Yes, I guess we could solve the problem by disabling the other rows. But
>>> remember that we still need to notify the model about the event, because
>>> we need to tell the user why the table focus did not move. This could be
>>> a message in the status bar or in an dialog. How would you solve this
>>> problem? One solution could be to still fire a selectionChanged event
>>> when the user moves to a "disabled cell" , but not move the cell focus.
>>>
>> This is your own task then by adding a keyboard and mouse listener, not
>> :-) IMHO it would be a bug if grid would fire an event in this situation.
>>
>> Tom
>>
>>
>> --
>> B e s t S o l u t i o n . at
>> ------------------------------------------------------------ --------
>> Tom Schindl JFace-Committer
>> ------------------------------------------------------------ --------
>
>
|
|
| |
| Re: How to cancel keyboard event in the Grid? [message #587294 is a reply to message #45436] |
Tue, 08 January 2008 10:15 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Chris.
Thanks for your answer. The reason why we want this feature is because we
want our underlying model to have complete control of what cell that has the
current focus in the Grid. For instance, when navigating in the Grid we
would like to be able to jump closed cells. Jumping cells in the current
implementation will cause flicker, because the Grid always moves to the
adjacent cell.
We imagine the event flow to be something like the following:
- The focus is in a table cell and the user presses "arrow right".
- The Grid notifies the model about the key press and does nothing more.
- The model interprets the key event and sends an event back to the Grid
telling it that the cell focus has changed.
- The Grid receives the event, reads the current cell from the model and
places the table cursor in the corresponding cell.
With the above design the navigation logic is moved from the Grid down into
the model. It is the model that tells the Grid what to do.
What do you think?
Best regards,
Anders
"Chris Gross" <chris.gross@us.ibm.com> wrote in message
news:flto77$pui$1@build.eclipse.org...
> Hi Anders,
>
> There's no way to prevent the event or its related processing but you can
> listen for the same event and set the cell focus/selection to whatever you
> wish. If this is something that you'd like to see added to the Grid I
> would ask that you explain the business need for a feature like this.
>
> Regards,
> -Chris
>
> Anders Baumann wrote:
>> How can I prevent the Grid from moving the cell focus when the user
>> presses the ARROW keys? I would like to do this, because I want the Grid
>> to ask the underlying model of what to do. I somehow need to cancel the
>> keyboard event, but I don't see how, because the method "onKeyDown" of
>> the Grid is private? Is there any way to cancel the event before it is
>> sent to "onKeyDown"?
>>
>> Thanks in advance,
>> Anders
>>
>>
>>
|
|
| |
| Re: How to cancel keyboard event in the Grid? [message #587319 is a reply to message #45675] |
Tue, 08 January 2008 12:29 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Tom and Chris.
Yes, if we could tell the Grid about "disabled cells" that would solve the
problem with jumping closed cell. But that was just one reason why I wanted
better control of the cell navigation.
Another reason: In our application you are not allowed to move to a new row
if you have dirty data in the current row. When the user tries to move to a
new row, either with the keyboard or the mouse, the application will not
move the table cursor, but instead tell the user that there is uncommitted
data in the current row. This design will cause flicker with the current
Grid implementation, because the Grid will first move the focus to the new
cell and then the model will put it back to the original cell.
Best regards,
Anders
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvj2c$eb9$1@build.eclipse.org...
> Anders Baumann schrieb:
>> Hi Chris.
>>
>> Thanks for your answer. The reason why we want this feature is because we
>> want our underlying model to have complete control of what cell that has
>> the current focus in the Grid. For instance, when navigating in the Grid
>> we would like to be able to jump closed cells. Jumping cells in the
>> current implementation will cause flicker, because the Grid always moves
>> to the adjacent cell.
>>
>> We imagine the event flow to be something like the following:
>>
>> - The focus is in a table cell and the user presses "arrow right".
>> - The Grid notifies the model about the key press and does nothing more.
>> - The model interprets the key event and sends an event back to the Grid
>> telling it that the cell focus has changed.
>> - The Grid receives the event, reads the current cell from the model and
>> places the table cursor in the corresponding cell.
>>
>> With the above design the navigation logic is moved from the Grid down
>> into the model. It is the model that tells the Grid what to do.
>>
>
> Shouldn't it better be moved to a controller? Maybe it would be sufficient
> to teach the Grid how to "disable cells" so they can't receive focus, ...,
> this would be a nice feature people are often requesting for
> SWT-Table/Tree anyways :-)
>
> Tom
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
| | |
| Re: How to cancel keyboard event in the Grid? [message #587358 is a reply to message #45762] |
Tue, 08 January 2008 12:52 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvqun$eha$2@build.eclipse.org...
> Tom Schindl schrieb:
>> Anders Baumann schrieb:
>>> Hi Tom and Chris.
>>>
>>> Yes, if we could tell the Grid about "disabled cells" that would solve
>>> the problem with jumping closed cell. But that was just one reason why I
>>> wanted better control of the cell navigation.
>>> Another reason: In our application you are not allowed to move to a new
>>> row if you have dirty data in the current row. When the user tries to
>>> move to a new row, either with the keyboard or the mouse, the
>>> application will not move the table cursor, but instead tell the user
>>> that there is uncommitted data in the current row. This design will
>>> cause flicker with the current Grid implementation, because the Grid
>>> will first move the focus to the new cell and then the model will put it
>>> back to the original cell.
>>
>> How do you handle the mouse in this situation, you'll also want to cancle
>> the mouse events?
>>
>
> What I wanted to say is that if you could "disable cells" this would solve
> this problem to because when a row is modified you'll have to put all
> cells beside the ones in the currently active row into disabled mode.
>
Yes, we would also cancel mouse events in this situation.
Yes, I guess we could solve the problem by disabling the other rows. But
remember that we still need to notify the model about the event, because we
need to tell the user why the table focus did not move. This could be a
message in the status bar or in an dialog. How would you solve this problem?
One solution could be to still fire a selectionChanged event when the user
moves to a "disabled cell" , but not move the cell focus.
/Anders
> Tom
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
| |
| Re: How to cancel keyboard event in the Grid? [message #587379 is a reply to message #45822] |
Tue, 08 January 2008 14:49 |
Anders Baumann
Messages: 55
Registered: July 2009 |
Member |
|
|
Hi Tom and Chris.
After thinking about this issue, I have realized that the "disabled cells"
would actually not solve our problem. We need a more flexible solution.
Sorry, but my first description of our application was incomplete. Here is
the correct one:
Two things can happens when a table row contains dirty data and the user
tries to move to another row:
1) The data in the current row is valid: The row is committed to the server
and the table focus is moved to the new row.
2) The data is invalid: The focus stays in the current table cell and a
dialog is shown to the user.
The table focus is moved in case 1, but not in case 2. However, we don't
know if the data is valid before it is sent to the server. This is why we
cannot use the "disabled cells" solution. Instead we would like the Grid to
tell the model about the event, but not move the focus. When the model has
validated the data it should tell the Grid to move the focus or not.
So, we would still like to be able to cancel both keyboard and mouse events
in the Grid. I hope that Chris will add this feature to the Grid. This would
be a great help and give us flexibility to also solve future related
problems.
Alernatively, it should be possible to replace the default keyboard listener
and mouse listener of the Grid. Most users would probably be happy with the
default solution, but it would enable us to implement our own version of
these listeners.
I hope my mail makes sense and thanks for taking the time to answer.
Best regards,
Anders
"Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
news:flvs3t$pqn$1@build.eclipse.org...
>
>>> What I wanted to say is that if you could "disable cells" this would
>>> solve this problem to because when a row is modified you'll have to put
>>> all cells beside the ones in the currently active row into disabled
>>> mode.
>>>
>>
>> Yes, we would also cancel mouse events in this situation.
>> Yes, I guess we could solve the problem by disabling the other rows. But
>> remember that we still need to notify the model about the event, because
>> we need to tell the user why the table focus did not move. This could be
>> a message in the status bar or in an dialog. How would you solve this
>> problem? One solution could be to still fire a selectionChanged event
>> when the user moves to a "disabled cell" , but not move the cell focus.
>>
>
> This is your own task then by adding a keyboard and mouse listener, not
> :-) IMHO it would be a bug if grid would fire an event in this situation.
>
> Tom
>
>
> --
> B e s t S o l u t i o n . at
> ------------------------------------------------------------ --------
> Tom Schindl JFace-Committer
> ------------------------------------------------------------ --------
|
|
|
| Re: How to cancel keyboard event in the Grid? [message #587417 is a reply to message #45852] |
Tue, 08 January 2008 23:13 |
Chris Gross
Messages: 471
Registered: July 2009 |
Senior Member |
|
|
Sounds like you are trying to do something rather atypical. I might
suggest trying to design an alternative UI. As it is now, I don't plan
on adding any features that would support this paradigm.
Regards,
-Chris
Anders Baumann wrote:
> Hi Tom and Chris.
>
> After thinking about this issue, I have realized that the "disabled cells"
> would actually not solve our problem. We need a more flexible solution.
>
> Sorry, but my first description of our application was incomplete. Here is
> the correct one:
>
> Two things can happens when a table row contains dirty data and the user
> tries to move to another row:
> 1) The data in the current row is valid: The row is committed to the server
> and the table focus is moved to the new row.
> 2) The data is invalid: The focus stays in the current table cell and a
> dialog is shown to the user.
>
> The table focus is moved in case 1, but not in case 2. However, we don't
> know if the data is valid before it is sent to the server. This is why we
> cannot use the "disabled cells" solution. Instead we would like the Grid to
> tell the model about the event, but not move the focus. When the model has
> validated the data it should tell the Grid to move the focus or not.
>
> So, we would still like to be able to cancel both keyboard and mouse events
> in the Grid. I hope that Chris will add this feature to the Grid. This would
> be a great help and give us flexibility to also solve future related
> problems.
>
> Alernatively, it should be possible to replace the default keyboard listener
> and mouse listener of the Grid. Most users would probably be happy with the
> default solution, but it would enable us to implement our own version of
> these listeners.
>
> I hope my mail makes sense and thanks for taking the time to answer.
>
> Best regards,
> Anders
>
>
>
>
> "Tom Schindl" <tom.schindl@bestsolution.at> wrote in message
> news:flvs3t$pqn$1@build.eclipse.org...
>>>> What I wanted to say is that if you could "disable cells" this would
>>>> solve this problem to because when a row is modified you'll have to put
>>>> all cells beside the ones in the currently active row into disabled
>>>> mode.
>>>>
>>> Yes, we would also cancel mouse events in this situation.
>>> Yes, I guess we could solve the problem by disabling the other rows. But
>>> remember that we still need to notify the model about the event, because
>>> we need to tell the user why the table focus did not move. This could be
>>> a message in the status bar or in an dialog. How would you solve this
>>> problem? One solution could be to still fire a selectionChanged event
>>> when the user moves to a "disabled cell" , but not move the cell focus.
>>>
>> This is your own task then by adding a keyboard and mouse listener, not
>> :-) IMHO it would be a bug if grid would fire an event in this situation.
>>
>> Tom
>>
>>
>> --
>> B e s t S o l u t i o n . at
>> ------------------------------------------------------------ --------
>> Tom Schindl JFace-Committer
>> ------------------------------------------------------------ --------
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 07:40:11 GMT 2024
Powered by FUDForum. Page generated in 0.05097 seconds |
] 
Search
Help
Register
Login
Home
