[news.eclipse.technology.nebula] Re: How to cancel keyboard event in the

["Anders Baumann" <anb@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxx> wrote in message 
news:flvs3t$pqn$1@xxxxxxxxxxxxxxxxxxxx
>
>>> 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
> --------------------------------------------------------------------