Home » Eclipse Projects » Eclipse Platform » Focus traversal and editable table cells
| Focus traversal and editable table cells [message #320908] |
Wed, 03 October 2007 17:43  |
Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
I've got a table with several editable columns, one of which uses a
CheckboxCellEditor. Because the CheckboxCellEditor has no Control, when
the focus is traversed into it, it just vanishes and no further keyboard
focus traversal works.
I'm trying to understand the new APIs in this area (TableViewerEditor,
ColumnViewerEditorActivationStrategy, etc) but they are poorly
documented and the snippets don't provide much help.
Any advice on getting sensible keyboard traversal of cell editors when a
CheckboxCellEditor (or other "invisible" CellEditor) is involved?
TIA,
Eric
|
|
| |
| Re: Focus traversal and editable table cells [message #320925 is a reply to message #320910] |
Wed, 03 October 2007 21:34  |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198502 Maybe you could
> mimic this your own somehow. As you notice the trick is to add a
> TraverseListener to the Tree/Table.
I tried looking at the final patch, but it is difficult to interpret
without actually applying it (which requires a check-out of JFace from
HEAD, IIUC). Can you give more detail about what is required to
implement the same thing in 3.3?
Thanks,
Eric
> Eric Rizzo schrieb:
>> I've got a table with several editable columns, one of which uses a
>> CheckboxCellEditor. Because the CheckboxCellEditor has no Control,
>> when the focus is traversed into it, it just vanishes and no further
>> keyboard focus traversal works.
>> I'm trying to understand the new APIs in this area (TableViewerEditor,
>> ColumnViewerEditorActivationStrategy, etc) but they are poorly
>> documented and the snippets don't provide much help.
>>
>> Any advice on getting sensible keyboard traversal of cell editors when
>> a CheckboxCellEditor (or other "invisible" CellEditor) is involved?
>>
>> TIA,
>> Eric
>
>
|
|
|
| Re: Focus traversal and editable table cells [message #320935 is a reply to message #320925] |
Thu, 04 October 2007 06:53 |
 Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
The trick is fairly simple but you may have to use reflection because I
think some of the methods you'll have to access are package scoped:
1. Attach a TraverseListener to your Table/Tree
2. In the TraverseListener check the current editor and if it is a
CheckBoxCellEditor move open the next editor (from the out-side easily
with TableViewer/TreeViewer#editElement)
Tom
Eric Rizzo schrieb:
> Tom Schindl wrote:
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198502 Maybe you could
>> mimic this your own somehow. As you notice the trick is to add a
>> TraverseListener to the Tree/Table.
>
> I tried looking at the final patch, but it is difficult to interpret
> without actually applying it (which requires a check-out of JFace from
> HEAD, IIUC). Can you give more detail about what is required to
> implement the same thing in 3.3?
>
> Thanks,
> Eric
>
>
>> Eric Rizzo schrieb:
>>> I've got a table with several editable columns, one of which uses a
>>> CheckboxCellEditor. Because the CheckboxCellEditor has no Control,
>>> when the focus is traversed into it, it just vanishes and no further
>>> keyboard focus traversal works.
>>> I'm trying to understand the new APIs in this area
>>> (TableViewerEditor, ColumnViewerEditorActivationStrategy, etc) but
>>> they are poorly documented and the snippets don't provide much help.
>>>
>>> Any advice on getting sensible keyboard traversal of cell editors
>>> when a CheckboxCellEditor (or other "invisible" CellEditor) is involved?
>>>
>>> TIA,
>>> Eric
>>
>>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
|
| Re: Focus traversal and editable table cells [message #320976 is a reply to message #320935] |
Thu, 04 October 2007 17:57 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> The trick is fairly simple but you may have to use reflection because I
> think some of the methods you'll have to access are package scoped:
>
> 1. Attach a TraverseListener to your Table/Tree
> 2. In the TraverseListener check the current editor and if it is a
> CheckBoxCellEditor move open the next editor (from the out-side easily
> with TableViewer/TreeViewer#editElement)
Unfortunately, that won't do - the checkbox cell should not be skipped
with keyboard traversal, I need it to actually hold the focus (and
respond to Space or Enter key by toggling the value).
I have to say, even with the new 3.3 table editing APIs, inline editable
tables feel like a bastard child of SWT/JFace. My client has pretty
basic requirements but I am having a very hard time finding solutions
that work even close to what they expect. I suspect that the reason this
kind of thing is not as easy or straightforward as the rest of SWT/JFace
is because there aren't any totally editable tables in the Eclipse
"core" plugins themselves. Since no Eclipse developers are doing
editable tables it sort-of explains why the functinality is not all
there. Sad, though - my client is somewhat losing faith in Eclipse UI
libraries because of these limitations, despite all the good things that
are provided in SWT+JFace+Forms.
Eric
> Eric Rizzo schrieb:
>> Tom Schindl wrote:
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=198502 Maybe you could
>>> mimic this your own somehow. As you notice the trick is to add a
>>> TraverseListener to the Tree/Table.
>>
>> I tried looking at the final patch, but it is difficult to interpret
>> without actually applying it (which requires a check-out of JFace from
>> HEAD, IIUC). Can you give more detail about what is required to
>> implement the same thing in 3.3?
>>
>> Thanks,
>> Eric
>>
>>
>>> Eric Rizzo schrieb:
>>>> I've got a table with several editable columns, one of which uses a
>>>> CheckboxCellEditor. Because the CheckboxCellEditor has no Control,
>>>> when the focus is traversed into it, it just vanishes and no further
>>>> keyboard focus traversal works.
>>>> I'm trying to understand the new APIs in this area
>>>> (TableViewerEditor, ColumnViewerEditorActivationStrategy, etc) but
>>>> they are poorly documented and the snippets don't provide much help.
>>>>
>>>> Any advice on getting sensible keyboard traversal of cell editors
>>>> when a CheckboxCellEditor (or other "invisible" CellEditor) is
>>>> involved?
>>>>
>>>> TIA,
>>>> Eric
>>>
>>>
>
>
|
|
| |
| Re: Focus traversal and editable table cells [message #320981 is a reply to message #320978] |
Thu, 04 October 2007 18:37 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------070009030607020702010906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Tom,
For the properties view, we've had to use your combo with true false
approach. I was hoping to make double click be a simple way to toggle
it, but that doesn't work.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196
I just added a vote for it.
Tom Schindl wrote:
> Eric Rizzo schrieb:
>> Tom Schindl wrote:
>>> The trick is fairly simple but you may have to use reflection
>>> because I think some of the methods you'll have to access are
>>> package scoped:
>>>
>>> 1. Attach a TraverseListener to your Table/Tree
>>> 2. In the TraverseListener check the current editor and if it is a
>>> CheckBoxCellEditor move open the next editor (from the out-side
>>> easily with TableViewer/TreeViewer#editElement)
>>
>> Unfortunately, that won't do - the checkbox cell should not be
>> skipped with keyboard traversal, I need it to actually hold the focus
>> (and respond to Space or Enter key by toggling the value).
>>
>
> But it isn't skipped only because you are adding a TraverseListener
> the editor is still active! At least the last time I tried my patch it
> worked this way in Snippet26.
>
>> I have to say, even with the new 3.3 table editing APIs, inline
>> editable tables feel like a bastard child of SWT/JFace. My client has
>> pretty basic requirements but I am having a very hard time finding
>> solutions that work even close to what they expect. I suspect that
>> the reason this kind of thing is not as easy or straightforward as
>> the rest of SWT/JFace is because there aren't any totally editable
>> tables in the Eclipse "core" plugins themselves. Since no Eclipse
>> developers are doing editable tables it sort-of explains why the
>> functinality is not all there. Sad, though - my client is somewhat
>> losing faith in Eclipse UI libraries because of these limitations,
>> despite all the good things that are provided in SWT+JFace+Forms.
>>
>
> I'm sad that we couldn't address all your needs in 3.3 but we are
> improving or at least are trying to. Where are the other problems you
> are facing with editing that makes you think inline-Editing is a
> bastard child of JFace. If you point out the areas we should improve
> I'm more than willing to do so (although JFace is not my daytime job
> I'm one of guys responsible to push it further).
>
> Maybe you could think of an alternate implementation of
> CheckboxCellEditor (e.g. a true/false DropDown comes to my mind or a
> reimplementation of CheckBoxCellEditor with Button() now that you can
> adjust line heights in Tables/Trees.
>
> Tom
>
--------------070009030607020702010906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom,<br>
<br>
For the properties view, we've had to use your combo with true false
approach. I was hoping to make double click be a simple way to toggle
it, but that doesn't work.<br>
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196">https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196</a><br>
</blockquote>
I just added a vote for it.<br>
<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:fe3ard$v2o$1@build.eclipse.org" type="cite">Eric
Rizzo schrieb:
<br>
<blockquote type="cite">Tom Schindl wrote:
<br>
<blockquote type="cite">The trick is fairly simple but you may have
to use reflection because I think some of the methods you'll have to
access are package scoped:
<br>
<br>
1. Attach a TraverseListener to your Table/Tree
<br>
2. In the TraverseListener check the current editor and if it is a
CheckBoxCellEditor move open the next editor (from the out-side easily
with TableViewer/TreeViewer#editElement)
<br>
</blockquote>
<br>
Unfortunately, that won't do - the checkbox cell should not be skipped
with keyboard traversal, I need it to actually hold the focus (and
respond to Space or Enter key by toggling the value).
<br>
<br>
</blockquote>
<br>
But it isn't skipped only because you are adding a TraverseListener the
editor is still active! At least the last time I tried my patch it
worked this way in Snippet26.
<br>
<br>
<blockquote type="cite">I have to say, even with the new 3.3 table
editing APIs, inline editable tables feel like a bastard child of
SWT/JFace. My client has pretty basic requirements but I am having a
very hard time finding solutions that work even close to what they
expect. I suspect that the reason this kind of thing is not as easy or
straightforward as the rest of SWT/JFace is because there aren't any
totally editable tables in the Eclipse "core" plugins themselves. Since
no Eclipse developers are doing editable tables it sort-of explains why
the functinality is not all there. Sad, though - my client is somewhat
losing faith in Eclipse UI libraries because of these limitations,
despite all the good things that are provided in SWT+JFace+Forms.
<br>
<br>
</blockquote>
<br>
I'm sad that we couldn't address all your needs in 3.3 but we are
improving or at least are trying to. Where are the other problems you
are facing with editing that makes you think inline-Editing is a
bastard child of JFace. If you point out the areas we should improve
I'm more than willing to do so (although JFace is not my daytime job
I'm one of guys responsible to push it further).
<br>
<br>
Maybe you could think of an alternate implementation of
CheckboxCellEditor (e.g. a true/false DropDown comes to my mind or a
reimplementation of CheckBoxCellEditor with Button() now that you can
adjust line heights in Tables/Trees.
<br>
<br>
Tom
<br>
<br>
</blockquote>
<br>
</body>
</html>
--------------070009030607020702010906--
|
|
| |
| Re: Focus traversal and editable table cells [message #320992 is a reply to message #320981] |
Thu, 04 October 2007 19:31 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
I've just uploaded a snippet and improved the patch for Bug 198502. The
trick is that one needs a CellFocusManager to make the whole thing work.
Tom
Ed Merks schrieb:
> Tom,
>
> For the properties view, we've had to use your combo with true false
> approach. I was hoping to make double click be a simple way to toggle
> it, but that doesn't work.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196
>
> I just added a vote for it.
>
>
> Tom Schindl wrote:
>> Eric Rizzo schrieb:
>>> Tom Schindl wrote:
>>>> The trick is fairly simple but you may have to use reflection
>>>> because I think some of the methods you'll have to access are
>>>> package scoped:
>>>>
>>>> 1. Attach a TraverseListener to your Table/Tree
>>>> 2. In the TraverseListener check the current editor and if it is a
>>>> CheckBoxCellEditor move open the next editor (from the out-side
>>>> easily with TableViewer/TreeViewer#editElement)
>>>
>>> Unfortunately, that won't do - the checkbox cell should not be
>>> skipped with keyboard traversal, I need it to actually hold the focus
>>> (and respond to Space or Enter key by toggling the value).
>>>
>>
>> But it isn't skipped only because you are adding a TraverseListener
>> the editor is still active! At least the last time I tried my patch it
>> worked this way in Snippet26.
>>
>>> I have to say, even with the new 3.3 table editing APIs, inline
>>> editable tables feel like a bastard child of SWT/JFace. My client has
>>> pretty basic requirements but I am having a very hard time finding
>>> solutions that work even close to what they expect. I suspect that
>>> the reason this kind of thing is not as easy or straightforward as
>>> the rest of SWT/JFace is because there aren't any totally editable
>>> tables in the Eclipse "core" plugins themselves. Since no Eclipse
>>> developers are doing editable tables it sort-of explains why the
>>> functinality is not all there. Sad, though - my client is somewhat
>>> losing faith in Eclipse UI libraries because of these limitations,
>>> despite all the good things that are provided in SWT+JFace+Forms.
>>>
>>
>> I'm sad that we couldn't address all your needs in 3.3 but we are
>> improving or at least are trying to. Where are the other problems you
>> are facing with editing that makes you think inline-Editing is a
>> bastard child of JFace. If you point out the areas we should improve
>> I'm more than willing to do so (although JFace is not my daytime job
>> I'm one of guys responsible to push it further).
>>
>> Maybe you could think of an alternate implementation of
>> CheckboxCellEditor (e.g. a true/false DropDown comes to my mind or a
>> reimplementation of CheckBoxCellEditor with Button() now that you can
>> adjust line heights in Tables/Trees.
>>
>> Tom
>>
>
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
| | |
| Re: Focus traversal and editable table cells [message #321003 is a reply to message #320978] |
Thu, 04 October 2007 22:02 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> Eric Rizzo schrieb:
>> I have to say, even with the new 3.3 table editing APIs, inline
>> editable tables feel like a bastard child of SWT/JFace. My client has
>> pretty basic requirements but I am having a very hard time finding
>> solutions that work even close to what they expect. I suspect that the
>> reason this kind of thing is not as easy or straightforward as the
>> rest of SWT/JFace is because there aren't any totally editable tables
>> in the Eclipse "core" plugins themselves. Since no Eclipse developers
>> are doing editable tables it sort-of explains why the functinality is
>> not all there. Sad, though - my client is somewhat losing faith in
>> Eclipse UI libraries because of these limitations, despite all the
>> good things that are provided in SWT+JFace+Forms.
>>
>
> I'm sad that we couldn't address all your needs in 3.3 but we are
> improving or at least are trying to. Where are the other problems you
> are facing with editing that makes you think inline-Editing is a bastard
> child of JFace. If you point out the areas we should improve I'm more
> than willing to do so (although JFace is not my daytime job I'm one of
> guys responsible to push it further).
I really appreciate the receptive attitude. The bottom line is that we
need a table (lots of them, actually) with various kinds of editable
columns (Text, Combo, Checkbox, and "clickable icon" (similar to
DialogCellEditor but without the Button)) that is also fully functional
using the keyboard. The client currently has this mostly implemented in
Swing and I am disappointed to not be able to implement the same thing
without patches, hokey reflection code, and hours upon hours of
digging/debugging through the SWT and JFace source code. Even with all
of that, I'm still not there yet (still have to try your latest patch
and snippet - thanks again).
In other words, cell editing works for checkboxes only through
simulation with coordinated LabelProvider, and it totally breaks tabbing
traversal through the cells. Same goes for any cell editor that doesn't
really have a Control to use (although I've managed to work around the
clickable icon case).
I think you're latest snippet might demonstrate what I need - I'll let
you know.
> Maybe you could think of an alternate implementation of
> CheckboxCellEditor (e.g. a true/false DropDown comes to my mind or a
> reimplementation of CheckBoxCellEditor with Button() now that you can
> adjust line heights in Tables/Trees.
I've suggested the drop-down alternative, but the UI designers would
prefer a checkbox and are still willing to pay to work towards that.
Using a Button has the problem that the button look ugly when it renders
next to the column label (a "cehckbox" image) and it requires two clicks
to change the value (my client has an aversion to what they consider
"too many" clicks required to do anything).
Hope this helps to expose the limitations - I think keyboard navigation
and activation is the key here; it works for Text and Combo, but not for
all types of editors.
Eric
|
|
| |
| Re: Focus traversal and editable table cells [message #321010 is a reply to message #321007] |
Fri, 05 October 2007 02:19 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> Eric Rizzo schrieb:
>> I've suggested the drop-down alternative, but the UI designers would
>> prefer a checkbox and are still willing to pay to work towards that.
>> Using a Button has the problem that the button look ugly when it
>> renders next to the column label (a "cehckbox" image) and it requires
>> two clicks to change the value (my client has an aversion to what they
>> consider "too many" clicks required to do anything).
>
> Well you can take screen shots of your buttons on the fly and use these
> icons when the CheckBox-Editor is not on.
>
> See
> http://tom-eclipse-dev.blogspot.com/2007/01/tableviewers-and -nativelooking.html
That's an interesting trick - something I actually asked about earlier
today on the SWT newsgroup - what a coincidence.
As handy as that is, it does not solve the problem I was trying to
describe above. With a label provider that returns an image, the image
remains visible even when the cell editor becomes active; you end up
with a real check button next to the simulated one. Unless you can point
me to a trick to NOT show the LabelProvider-provided image when the
editor is shown...
Thanks again,
Eric
|
|
| |
| Re: Focus traversal and editable table cells [message #321036 is a reply to message #320996] |
Fri, 05 October 2007 16:06 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> And I prove myself once more wrong. The whole thing works with 3.3.1,
> FocusCellManager and EditorActivation.
>
> The only method that has to be reached with reflection is
> ColumnViewerEditor#processTraverseEvent but because method is protected
> it is part of the offical API and won't get broken in up-coming releases.
Snippet 048 does appear to do it, but unfortunately I can not rely on
SWT/JFace 3.3.1 - my client wants to be able to support 3.3 and not have
the QA and support overhead of using separate 3.3.1-specific code. I
don't personally agree with that decision (seems like a 3.3.1 upgrade
requirement would not be likely to alienate very many users), but it's
not my decision to make.
I'm wondering if there is some way to use the code from Snippet 048 but
workaround the problem of the value toggling whenever the cell is tabbed
into (in 3.3)...
Eric
|
|
|
| Re: Focus traversal and editable table cells [message #321037 is a reply to message #320996] |
Fri, 05 October 2007 16:08 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom,
Thanks again for your help on this issue. I look forward to bug 198502
being fixed completely in 3.4 - the product I'm working on is due to be
released not long before that, so at least we can leverage 3.4 in a
quick patch. Is there anything I can do to help encourage that bug to be
fixed for certain in 3.4?
|
|
| |
| Re: Focus traversal and editable table cells [message #321070 is a reply to message #321038] |
Mon, 08 October 2007 02:50 |
| Eclipse User |
|
|
|
Originally posted by: eclipse6.rizzoweb.com
Tom Schindl wrote:
> Hi,
>
> Yes you subclass your CheckBoxCellEditor and port the patch that was
> released to 3.3.1.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=199775
Eureka! The combination of applying the simple override of
activate(ColumnViewerEditorActivationEvent activationEvent) to a custom
CheckboxCellEditor and the (admittedly complex) code from Snippet 048
did the trick.
Things are looking up and I'm sure my client will be pleased at tomorrow
morning's SCRUM meeting ;-)
Thanks, Tom, for persevering with me on this. If you're ever in Florida
please look me up and we can share a beverage of your choice :-)
Eric
> Eric Rizzo schrieb:
>> Tom Schindl wrote:
>>> And I prove myself once more wrong. The whole thing works with 3.3.1,
>>> FocusCellManager and EditorActivation.
>>>
>>> The only method that has to be reached with reflection is
>>> ColumnViewerEditor#processTraverseEvent but because method is
>>> protected it is part of the offical API and won't get broken in
>>> up-coming releases.
>>
>> Snippet 048 does appear to do it, but unfortunately I can not rely on
>> SWT/JFace 3.3.1 - my client wants to be able to support 3.3 and not
>> have the QA and support overhead of using separate 3.3.1-specific
>> code. I don't personally agree with that decision (seems like a 3.3.1
>> upgrade requirement would not be likely to alienate very many users),
>> but it's not my decision to make.
>>
>> I'm wondering if there is some way to use the code from Snippet 048
>> but workaround the problem of the value toggling whenever the cell is
>> tabbed into (in 3.3)...
>>
>> Eric
>
>
|
|
| | |
Goto Forum:
Current Time: Fri Apr 26 10:15:33 GMT 2024
Powered by FUDForum. Page generated in 0.05643 seconds |
] 
Search
Help
Register
Login
Home
