Eclipse Community Forums: Eclipse Platform » Focus traversal and editable table cells

Home » Eclipse Projects » Eclipse Platform » Focus traversal and editable table cells

Focus traversal and editable table cells [message #320908]

Wed, 03 October 2007 13: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 #320910 is a reply to message #320908]

Wed, 03 October 2007 14:00

Eclipse User

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.

Tom
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 #320925 is a reply to message #320910]

Wed, 03 October 2007 17: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 02:53

Eclipse User

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 13: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 #320978 is a reply to message #320976]

Thu, 04 October 2007 14:19

Eclipse User

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 #320981 is a reply to message #320978]

Thu, 04 October 2007 14: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, 
 
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. 
<blockquote><a
href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196">https://bugs.eclipse.org/bugs/show_bug.cgi?id=182196</a> 
</blockquote>
I just added a vote for it. 
 
 
Tom Schindl wrote:
<blockquote cite="mid:fe3ard$v2o$1@build.eclipse.org" type="cite">Eric
Rizzo schrieb:
 
<blockquote type="cite">Tom Schindl wrote:
 
<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:
 
 
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)
 
</blockquote>
 
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).
 
 
</blockquote>
 
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.
 
 
<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.
 
 
</blockquote>
 
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
 
 
</blockquote>
 
</body>
</html>

--------------070009030607020702010906--

Re: Focus traversal and editable table cells [message #320986 is a reply to message #320978]

Thu, 04 October 2007 15:09

Eclipse User

Tom Schindl schrieb:
> 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.
>

Sorry you are right I am wrong :-(. The editor is deactivated
immediately so it might get tricky to fix it you are right.

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 #320992 is a reply to message #320981]

Thu, 04 October 2007 15:31

Eclipse User

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 #320996 is a reply to message #320986]

Thu, 04 October 2007 16:01

Eclipse User

This is a multi-part message in MIME format.
--------------080903040305090700050508
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.

I admit that one has to have in depth knowledge how the whole Viewer and
EditingSupport thingie is working but I have no time to write up these
things.

Tom

Tom Schindl schrieb:
> Tom Schindl schrieb:
>> 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.
>>
>
> Sorry you are right I am wrong :-(. The editor is deactivated
> immediately so it might get tricky to fix it you are right.
>
> Tom
>

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

--------------080903040305090700050508
Content-Type: text/plain;
name="Snippet048TreeViewerTabWithCheckboxFor3_3.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Snippet048TreeViewerTabWithCheckboxFor3_3.java"

LyoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioKICogQ29weXJpZ2h0IChjKSAy MDA2IFRvbSBT
Y2hpbmRsIGFuZCBvdGhlcnMuCiAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuIFRo aXMgcHJvZ3Jh
bSBhbmQgdGhlIGFjY29tcGFueWluZyBtYXRlcmlhbHMKICogYXJlIG1hZGUg YXZhaWxhYmxl
IHVuZGVyIHRoZSB0ZXJtcyBvZiB0aGUgRWNsaXBzZSBQdWJsaWMgTGljZW5z ZSB2MS4wCiAq
IHdoaWNoIGFjY29tcGFuaWVzIHRoaXMgZGlzdHJpYnV0aW9uLCBhbmQgaXMg YXZhaWxhYmxl
IGF0CiAqIGh0dHA6Ly93d3cuZWNsaXBzZS5vcmcvbGVnYWwvZXBsLXYxMC5o dG1sCiAqCiAq
IENvbnRyaWJ1dG9yczoKICogICAgIFRvbSBTY2hpbmRsIC0gaW5pdGlhbCBB UEkgYW5kIGlt
cGxlbWVudGF0aW9uCiAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqLwoKcGFj a2FnZSBvcmcu
ZWNsaXBzZS5qZmFjZS5zbmlwcGV0cy52aWV3ZXJzOwoKaW1wb3J0IGphdmEu bGFuZy5yZWZs
ZWN0Lkludm9jYXRpb25UYXJnZXRFeGNlcHRpb247CmltcG9ydCBqYXZhLmxh bmcucmVmbGVj
dC5NZXRob2Q7CmltcG9ydCBqYXZhLnV0aWwuQXJyYXlMaXN0OwoKaW1wb3J0 IG9yZy5lY2xp
cHNlLmpmYWNlLnZpZXdlcnMuQ2VsbEVkaXRvcjsKaW1wb3J0IG9yZy5lY2xp cHNlLmpmYWNl
LnZpZXdlcnMuQ2hlY2tib3hDZWxsRWRpdG9yOwppbXBvcnQgb3JnLmVjbGlw c2UuamZhY2Uu
dmlld2Vycy5Db2x1bW5MYWJlbFByb3ZpZGVyOwppbXBvcnQgb3JnLmVjbGlw c2UuamZhY2Uu
dmlld2Vycy5Db2x1bW5WaWV3ZXJFZGl0b3I7CmltcG9ydCBvcmcuZWNsaXBz ZS5qZmFjZS52
aWV3ZXJzLkNvbHVtblZpZXdlckVkaXRvckFjdGl2YXRpb25TdHJhdGVneTsK aW1wb3J0IG9y
Zy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuRWRpdGluZ1N1cHBvcnQ7CmltcG9y dCBvcmcuZWNs
aXBzZS5qZmFjZS52aWV3ZXJzLkNvbHVtblZpZXdlckVkaXRvckFjdGl2YXRp b25FdmVudDsK
aW1wb3J0IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuRm9jdXNDZWxsT3du ZXJEcmF3SGln
aGxpZ2h0ZXI7CmltcG9ydCBvcmcuZWNsaXBzZS5qZmFjZS52aWV3ZXJzLklU cmVlQ29udGVu
dFByb3ZpZGVyOwppbXBvcnQgb3JnLmVjbGlwc2UuamZhY2Uudmlld2Vycy5U ZXh0Q2VsbEVk
aXRvcjsKaW1wb3J0IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuVHJlZVZp ZXdlckVkaXRv
cjsKaW1wb3J0IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuVHJlZVZpZXdl cjsKaW1wb3J0
IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuVHJlZVZpZXdlckNvbHVtbjsK aW1wb3J0IG9y
Zy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuVHJlZVZpZXdlckZvY3VzQ2VsbE1h bmFnZXI7Cmlt
cG9ydCBvcmcuZWNsaXBzZS5qZmFjZS52aWV3ZXJzLlZpZXdlcjsKaW1wb3J0 IG9yZy5lY2xp
cHNlLmpmYWNlLnZpZXdlcnMuVmlld2VyQ2VsbDsKaW1wb3J0IG9yZy5lY2xp cHNlLmpmYWNl
LnZpZXdlcnMuVmlld2VyUm93OwppbXBvcnQgb3JnLmVjbGlwc2Uuc3d0LlNX VDsKaW1wb3J0
IG9yZy5lY2xpcHNlLnN3dC5ldmVudHMuS2V5RXZlbnQ7CmltcG9ydCBvcmcu ZWNsaXBzZS5z
d3QuZXZlbnRzLktleUxpc3RlbmVyOwppbXBvcnQgb3JnLmVjbGlwc2Uuc3d0 LmV2ZW50cy5T
ZWxlY3Rpb25FdmVudDsKaW1wb3J0IG9yZy5lY2xpcHNlLnN3dC5ldmVudHMu U2VsZWN0aW9u
TGlzdGVuZXI7CmltcG9ydCBvcmcuZWNsaXBzZS5zd3QuZXZlbnRzLlRyYXZl cnNlRXZlbnQ7
CmltcG9ydCBvcmcuZWNsaXBzZS5zd3QuZXZlbnRzLlRyYXZlcnNlTGlzdGVu ZXI7CmltcG9y
dCBvcmcuZWNsaXBzZS5zd3QubGF5b3V0LkZpbGxMYXlvdXQ7CmltcG9ydCBv cmcuZWNsaXBz
ZS5zd3Qud2lkZ2V0cy5CdXR0b247CmltcG9ydCBvcmcuZWNsaXBzZS5zd3Qu d2lkZ2V0cy5E
aXNwbGF5OwppbXBvcnQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMuU2hlbGw7 CgovKioKICog
QSBzaW1wbGUgVHJlZVZpZXdlciB0byBkZW1vbnN0cmF0ZSB1c2FnZQogKgog KiBAYXV0aG9y
IFRvbSBTY2hpbmRsIDx0b20uc2NoaW5kbEBiZXN0c29sdXRpb24uYXQ+CiAq CiAqLwpwdWJs
aWMgY2xhc3MgU25pcHBldDA0OFRyZWVWaWV3ZXJUYWJXaXRoQ2hlY2tib3hG b3IzXzMgewoJ
cHVibGljIFNuaXBwZXQwNDhUcmVlVmlld2VyVGFiV2l0aENoZWNrYm94Rm9y M18zKGZpbmFs
IFNoZWxsIHNoZWxsKSB7CgkJZmluYWwgVHJlZVZpZXdlciB2ID0gbmV3IFRy ZWVWaWV3ZXIo
c2hlbGwsIFNXVC5CT1JERVIKCQkJCXwgU1dULkZVTExfU0VMRUNUSU9OKTsK CQl2LmdldFRy
ZWUoKS5zZXRMaW5lc1Zpc2libGUodHJ1ZSk7CgkJdi5nZXRUcmVlKCkuc2V0 SGVhZGVyVmlz
aWJsZSh0cnVlKTsKCgkJZmluYWwgVHJlZVZpZXdlckZvY3VzQ2VsbE1hbmFn ZXIgbWdyID0g
bmV3IFRyZWVWaWV3ZXJGb2N1c0NlbGxNYW5hZ2VyKHYsbmV3IEZvY3VzQ2Vs bE93bmVyRHJh
d0hpZ2hsaWdodGVyKHYpKTsKCQlDb2x1bW5WaWV3ZXJFZGl0b3JBY3RpdmF0 aW9uU3RyYXRl
Z3kgYWN0U3VwcG9ydCA9IG5ldyBDb2x1bW5WaWV3ZXJFZGl0b3JBY3RpdmF0 aW9uU3RyYXRl
Z3kodikgewoJCQlwcm90ZWN0ZWQgYm9vbGVhbiBpc0VkaXRvckFjdGl2YXRp b25FdmVudCgK
CQkJCQlDb2x1bW5WaWV3ZXJFZGl0b3JBY3RpdmF0aW9uRXZlbnQgZXZlbnQp IHsKCQkJCXJl
dHVybiBldmVudC5ldmVudFR5cGUgPT0gQ29sdW1uVmlld2VyRWRpdG9yQWN0 aXZhdGlvbkV2
ZW50LlRSQVZFUlNBTAoJCQkJCQl8fCBldmVudC5ldmVudFR5cGUgPT0gQ29s dW1uVmlld2Vy
RWRpdG9yQWN0aXZhdGlvbkV2ZW50Lk1PVVNFX0RPVUJMRV9DTElDS19TRUxF Q1RJT04KCQkJ
CQkJfHwgKGV2ZW50LmV2ZW50VHlwZSA9PSBDb2x1bW5WaWV3ZXJFZGl0b3JB Y3RpdmF0aW9u
RXZlbnQuS0VZX1BSRVNTRUQgJiYgKCBldmVudC5rZXlDb2RlID09IFNXVC5D UiB8fCBldmVu
dC5jaGFyYWN0ZXIgPT0gJyAnICkpCgkJCQkJCXx8IGV2ZW50LmV2ZW50VHlw ZSA9PSBDb2x1
bW5WaWV3ZXJFZGl0b3JBY3RpdmF0aW9uRXZlbnQuUFJPR1JBTU1BVElDOwoJ CQl9CgkJfTsK
CgkJVHJlZVZpZXdlckVkaXRvci5jcmVhdGUodiwgbWdyLCBhY3RTdXBwb3J0 LCBDb2x1bW5W
aWV3ZXJFZGl0b3IuVEFCQklOR19IT1JJWk9OVEFMCgkJCQl8IENvbHVtblZp ZXdlckVkaXRv
ci5UQUJCSU5HX01PVkVfVE9fUk9XX05FSUdIQk9SCgkJCQl8IENvbHVtblZp ZXdlckVkaXRv
ci5UQUJCSU5HX1ZFUlRJQ0FMIHwgQ29sdW1uVmlld2VyRWRpdG9yLktFWUJP QVJEX0FDVElW
QVRJT04pOwoKCQlmaW5hbCBUZXh0Q2VsbEVkaXRvciB0ZXh0Q2VsbEVkaXRv ciA9IG5ldyBU
ZXh0Q2VsbEVkaXRvcih2LmdldFRyZWUoKSk7CgkJZmluYWwgQ2hlY2tib3hD ZWxsRWRpdG9y
IGNoZWNrYm94Q2VsbEVkaXRvciA9IG5ldyBDaGVja2JveENlbGxFZGl0b3Io di5nZXRUcmVl
KCkpOwoKCQlUcmVlVmlld2VyQ29sdW1uIGNvbHVtbiA9IG5ldyBUcmVlVmll d2VyQ29sdW1u
KHYsIFNXVC5OT05FKTsKCQljb2x1bW4uZ2V0Q29sdW1uKCkuc2V0V2lkdGgo MjAwKTsKCQlj
b2x1bW4uZ2V0Q29sdW1uKCkuc2V0TW92ZWFibGUodHJ1ZSk7CgkJY29sdW1u LmdldENvbHVt
bigpLnNldFRleHQoIkNvbHVtbiAxIik7CgkJY29sdW1uLnNldExhYmVsUHJv dmlkZXIobmV3
IENvbHVtbkxhYmVsUHJvdmlkZXIoKSB7CgoJCQlwdWJsaWMgU3RyaW5nIGdl dFRleHQoT2Jq
ZWN0IGVsZW1lbnQpIHsKCQkJCXJldHVybiAiQ29sdW1uIDEgPT4gIiArIGVs ZW1lbnQudG9T
dHJpbmcoKTsKCQkJfQoKCQl9KTsKCQljb2x1bW4uc2V0RWRpdGluZ1N1cHBv cnQobmV3IEVk
aXRpbmdTdXBwb3J0KHYpIHsKCQkJcHJvdGVjdGVkIGJvb2xlYW4gY2FuRWRp dChPYmplY3Qg
ZWxlbWVudCkgewoJCQkJcmV0dXJuIGZhbHNlOwoJCQl9CgoJCQlwcm90ZWN0 ZWQgQ2VsbEVk
aXRvciBnZXRDZWxsRWRpdG9yKE9iamVjdCBlbGVtZW50KSB7CgkJCQlyZXR1 cm4gdGV4dENl
bGxFZGl0b3I7CgkJCX0KCgkJCXByb3RlY3RlZCBPYmplY3QgZ2V0VmFsdWUo T2JqZWN0IGVs
ZW1lbnQpIHsKCQkJCXJldHVybiAoKE15TW9kZWwpIGVsZW1lbnQpLmNvdW50 ZXIgKyAiIjsK
CQkJfQoKCQkJcHJvdGVjdGVkIHZvaWQgc2V0VmFsdWUoT2JqZWN0IGVsZW1l bnQsIE9iamVj
dCB2YWx1ZSkgewoJCQkJKChNeU1vZGVsKSBlbGVtZW50KS5jb3VudGVyID0g SW50ZWdlcgoJ
CQkJCQkucGFyc2VJbnQodmFsdWUudG9TdHJpbmcoKSk7CgkJCQl2LnVwZGF0 ZShlbGVtZW50
LCBudWxsKTsKCQkJfQoJCX0pOwoKCQljb2x1bW4gPSBuZXcgVHJlZVZpZXdl ckNvbHVtbih2
LCBTV1QuTk9ORSk7CgkJY29sdW1uLmdldENvbHVtbigpLnNldFdpZHRoKDIw MCk7CgkJY29s
dW1uLmdldENvbHVtbigpLnNldE1vdmVhYmxlKHRydWUpOwoJCWNvbHVtbi5n ZXRDb2x1bW4o
KS5zZXRUZXh0KCJDb2x1bW4gMiIpOwoJCWNvbHVtbi5zZXRMYWJlbFByb3Zp ZGVyKG5ldyBD
b2x1bW5MYWJlbFByb3ZpZGVyKCkgewoKCQkJcHVibGljIFN0cmluZyBnZXRU ZXh0KE9iamVj
dCBlbGVtZW50KSB7CgkJCQlyZXR1cm4gIkNvbHVtbiAyID0+ICIgKyBlbGVt ZW50LnRvU3Ry
aW5nKCk7CgkJCX0KCgkJfSk7CgkJY29sdW1uLnNldEVkaXRpbmdTdXBwb3J0 KG5ldyBFZGl0
aW5nU3VwcG9ydCh2KSB7CgkJCXByb3RlY3RlZCBib29sZWFuIGNhbkVkaXQo T2JqZWN0IGVs
ZW1lbnQpIHsKCQkJCXJldHVybiB0cnVlOwoJCQl9CgoJCQlwcm90ZWN0ZWQg Q2VsbEVkaXRv
ciBnZXRDZWxsRWRpdG9yKE9iamVjdCBlbGVtZW50KSB7CgkJCQlyZXR1cm4g dGV4dENlbGxF
ZGl0b3I7CgkJCX0KCgkJCXByb3RlY3RlZCBPYmplY3QgZ2V0VmFsdWUoT2Jq ZWN0IGVsZW1l
bnQpIHsKCQkJCXJldHVybiAoKE15TW9kZWwpIGVsZW1lbnQpLmNvdW50ZXIg KyAiIjsKCQkJ
fQoKCQkJcHJvdGVjdGVkIHZvaWQgc2V0VmFsdWUoT2JqZWN0IGVsZW1lbnQs IE9iamVjdCB2
YWx1ZSkgewoJCQkJKChNeU1vZGVsKSBlbGVtZW50KS5jb3VudGVyID0gSW50 ZWdlcgoJCQkJ
LnBhcnNlSW50KHZhbHVlLnRvU3RyaW5nKCkpOwoJCQkJdi51cGRhdGUoZWxl bWVudCwgbnVs
bCk7CgkJCX0KCQl9KTsKCgkJY29sdW1uID0gbmV3IFRyZWVWaWV3ZXJDb2x1 bW4odiwgU1dU
Lk5PTkUpOwoJCWNvbHVtbi5nZXRDb2x1bW4oKS5zZXRXaWR0aCgyMDApOwoJ CWNvbHVtbi5n
ZXRDb2x1bW4oKS5zZXRNb3ZlYWJsZSh0cnVlKTsKCQljb2x1bW4uZ2V0Q29s dW1uKCkuc2V0
VGV4dCgiQ29sdW1uIDMiKTsKCQljb2x1bW4uc2V0TGFiZWxQcm92aWRlcihu ZXcgQ29sdW1u
TGFiZWxQcm92aWRlcigpIHsKCgkJCXB1YmxpYyBTdHJpbmcgZ2V0VGV4dChP YmplY3QgZWxl
bWVudCkgewoJCQkJcmV0dXJuICgoTXlNb2RlbCllbGVtZW50KS5ib29sICsg IiI7CgkJCX0K
CgkJfSk7CgkJY29sdW1uLnNldEVkaXRpbmdTdXBwb3J0KG5ldyBFZGl0aW5n U3VwcG9ydCh2
KSB7CgkJCXByb3RlY3RlZCBib29sZWFuIGNhbkVkaXQoT2JqZWN0IGVsZW1l bnQpIHsKCQkJ
CXJldHVybiB0cnVlOwoJCQl9CgoJCQlwcm90ZWN0ZWQgQ2VsbEVkaXRvciBn ZXRDZWxsRWRp
dG9yKE9iamVjdCBlbGVtZW50KSB7CgkJCQlyZXR1cm4gY2hlY2tib3hDZWxs RWRpdG9yOwoJ
CQl9CgoJCQlwcm90ZWN0ZWQgT2JqZWN0IGdldFZhbHVlKE9iamVjdCBlbGVt ZW50KSB7CgkJ
CQlyZXR1cm4gbmV3IEJvb2xlYW4oKChNeU1vZGVsKSBlbGVtZW50KS5ib29s KTsKCQkJfQoK
CQkJcHJvdGVjdGVkIHZvaWQgc2V0VmFsdWUoT2JqZWN0IGVsZW1lbnQsIE9i amVjdCB2YWx1
ZSkgewoJCQkJKChNeU1vZGVsKSBlbGVtZW50KS5ib29sID0gKChCb29sZWFu KXZhbHVlKS5i
b29sZWFuVmFsdWUoKTsKCQkJCXYudXBkYXRlKGVsZW1lbnQsIG51bGwpOwoJ CQl9CgkJfSk7
CgoJCXYuc2V0Q29udGVudFByb3ZpZGVyKG5ldyBNeUNvbnRlbnRQcm92aWRl cigpKTsKCQl2
LnNldElucHV0KGNyZWF0ZU1vZGVsKCkpOwoJCXYuZ2V0Q29udHJvbCgpLmFk ZFRyYXZlcnNl
TGlzdGVuZXIobmV3IFRyYXZlcnNlTGlzdGVuZXIoKSB7CgoJCQlwdWJsaWMg dm9pZCBrZXlU
cmF2ZXJzZWQoVHJhdmVyc2VFdmVudCBlKSB7CgkJCQlpZiggKGUuZGV0YWls ID09IFNXVC5U
UkFWRVJTRV9UQUJfTkVYVCB8fCBlLmRldGFpbCA9PSBTV1QuVFJBVkVSU0Vf VEFCX1BSRVZJ
T1VTKSAmJiBtZ3IuZ2V0Rm9jdXNDZWxsKCkuZ2V0Q29sdW1uSW5kZXgoKSA9 PSAyICkgewoJ
CQkJCUNvbHVtblZpZXdlckVkaXRvciBlZGl0b3IgPSB2LmdldENvbHVtblZp ZXdlckVkaXRv
cigpOwoJCQkJCVZpZXdlckNlbGwgY2VsbCA9IG1nci5nZXRGb2N1c0NlbGwo KTsKCgkJCQkJ
dHJ5IHsKCQkJCQkJTWV0aG9kIG0gPSBDb2x1bW5WaWV3ZXJFZGl0b3IuY2xh c3MuZ2V0RGVj
bGFyZWRNZXRob2QoInByb2Nlc3NUcmF2ZXJzZUV2ZW50IiwgbmV3IENsYXNz W10ge2ludC5j
bGFzcyxWaWV3ZXJSb3cuY2xhc3MsVHJhdmVyc2VFdmVudC5jbGFzc30pOwoJ CQkJCQltLnNl
dEFjY2Vzc2libGUodHJ1ZSk7CgkJCQkJCW0uaW52b2tlKGVkaXRvciwgbmV3 IE9iamVjdFtd
IHsgbmV3IEludGVnZXIoY2VsbC5nZXRDb2x1bW5JbmRleCgpKSwgY2VsbC5n ZXRWaWV3ZXJS
b3coKSwgZSB9KTsKCQkJCQl9IGNhdGNoIChTZWN1cml0eUV4Y2VwdGlvbiBl MSkgewoJCQkJ
CQkvLyBUT0RPIEF1dG8tZ2VuZXJhdGVkIGNhdGNoIGJsb2NrCgkJCQkJCWUx LnByaW50U3Rh
Y2tUcmFjZSgpOwoJCQkJCX0gY2F0Y2ggKE5vU3VjaE1ldGhvZEV4Y2VwdGlv biBlMSkgewoJ
CQkJCQkvLyBUT0RPIEF1dG8tZ2VuZXJhdGVkIGNhdGNoIGJsb2NrCgkJCQkJ CWUxLnByaW50
U3RhY2tUcmFjZSgpOwoJCQkJCX0gY2F0Y2ggKElsbGVnYWxBcmd1bWVudEV4 Y2VwdGlvbiBl
MSkgewoJCQkJCQkvLyBUT0RPIEF1dG8tZ2VuZXJhdGVkIGNhdGNoIGJsb2Nr CgkJCQkJCWUx
LnByaW50U3RhY2tUcmFjZSgpOwoJCQkJCX0gY2F0Y2ggKElsbGVnYWxBY2Nl c3NFeGNlcHRp
b24gZTEpIHsKCQkJCQkJLy8gVE9ETyBBdXRvLWdlbmVyYXRlZCBjYXRjaCBi bG9jawoJCQkJ
CQllMS5wcmludFN0YWNrVHJhY2UoKTsKCQkJCQl9IGNhdGNoIChJbnZvY2F0 aW9uVGFyZ2V0
RXhjZXB0aW9uIGUxKSB7CgkJCQkJCS8vIFRPRE8gQXV0by1nZW5lcmF0ZWQg Y2F0Y2ggYmxv
Y2sKCQkJCQkJZTEucHJpbnRTdGFja1RyYWNlKCk7CgkJCQkJfQoJCQkJfQoJ CQl9CgoJCX0p
OwoJfQoKCXByaXZhdGUgTXlNb2RlbCBjcmVhdGVNb2RlbCgpIHsKCgkJTXlN b2RlbCByb290
ID0gbmV3IE15TW9kZWwoMCwgbnVsbCk7CgkJcm9vdC5jb3VudGVyID0gMDsK CgkJTXlNb2Rl
bCB0bXA7CgkJTXlNb2RlbCBzdWJJdGVtOwoJCWZvciAoaW50IGkgPSAxOyBp IDwgMTA7IGkr
KykgewoJCQl0bXAgPSBuZXcgTXlNb2RlbChpLCByb290KTsKCQkJcm9vdC5j aGlsZC5hZGQo
dG1wKTsKCQkJZm9yIChpbnQgaiA9IDE7IGogPCBpOyBqKyspIHsKCQkJCXN1 Ykl0ZW0gPSBu
ZXcgTXlNb2RlbChqLCB0bXApOwoJCQkJc3ViSXRlbS5jaGlsZC5hZGQobmV3 IE15TW9kZWwo
aiAqIDEwMCwgc3ViSXRlbSkpOwoJCQkJdG1wLmNoaWxkLmFkZChzdWJJdGVt KTsKCQkJfQoJ
CX0KCgkJcmV0dXJuIHJvb3Q7Cgl9CgoJcHVibGljIHN0YXRpYyB2b2lkIG1h aW4oU3RyaW5n
W10gYXJncykgewoJCURpc3BsYXkgZGlzcGxheSA9IG5ldyBEaXNwbGF5KCk7 CgkJU2hlbGwg
c2hlbGwgPSBuZXcgU2hlbGwoZGlzcGxheSk7CgkJc2hlbGwuc2V0TGF5b3V0 KG5ldyBGaWxs
TGF5b3V0KCkpOwoJCW5ldyBTbmlwcGV0MDQ4VHJlZVZpZXdlclRhYldpdGhD aGVja2JveEZv
cjNfMyhzaGVsbCk7CgkJc2hlbGwub3BlbigpOwoKCQl3aGlsZSAoIXNoZWxs LmlzRGlzcG9z
ZWQoKSkgewoJCQlpZiAoIWRpc3BsYXkucmVhZEFuZERpc3BhdGNoKCkpCgkJ CQlkaXNwbGF5
LnNsZWVwKCk7CgkJfQoKCQlkaXNwbGF5LmRpc3Bvc2UoKTsKCX0KCglwcml2 YXRlIGNsYXNz
IE15Q29udGVudFByb3ZpZGVyIGltcGxlbWVudHMgSVRyZWVDb250ZW50UHJv dmlkZXIgewoK
CQlwdWJsaWMgT2JqZWN0W10gZ2V0RWxlbWVudHMoT2JqZWN0IGlucHV0RWxl bWVudCkgewoJ
CQlyZXR1cm4gKChNeU1vZGVsKSBpbnB1dEVsZW1lbnQpLmNoaWxkLnRvQXJy YXkoKTsKCQl9
CgoJCXB1YmxpYyB2b2lkIGRpc3Bvc2UoKSB7CgkJfQoKCQlwdWJsaWMgdm9p ZCBpbnB1dENo
YW5nZWQoVmlld2VyIHZpZXdlciwgT2JqZWN0IG9sZElucHV0LCBPYmplY3Qg bmV3SW5wdXQp
IHsKCQl9CgoJCXB1YmxpYyBPYmplY3RbXSBnZXRDaGlsZHJlbihPYmplY3Qg cGFyZW50RWxl
bWVudCkgewoJCQlyZXR1cm4gZ2V0RWxlbWVudHMocGFyZW50RWxlbWVudCk7 CgkJfQoKCQlw
dWJsaWMgT2JqZWN0IGdldFBhcmVudChPYmplY3QgZWxlbWVudCkgewoJCQlp ZiAoZWxlbWVu
dCA9PSBudWxsKSB7CgkJCQlyZXR1cm4gbnVsbDsKCQkJfQoJCQlyZXR1cm4g KChNeU1vZGVs
KSBlbGVtZW50KS5wYXJlbnQ7CgkJfQoKCQlwdWJsaWMgYm9vbGVhbiBoYXND aGlsZHJlbihP
YmplY3QgZWxlbWVudCkgewoJCQlyZXR1cm4gKChNeU1vZGVsKSBlbGVtZW50 KS5jaGlsZC5z
aXplKCkgPiAwOwoJCX0KCgl9CgoJcHVibGljIGNsYXNzIE15TW9kZWwgewoJ CXB1YmxpYyBN
eU1vZGVsIHBhcmVudDsKCgkJcHVibGljIEFycmF5TGlzdCBjaGlsZCA9IG5l dyBBcnJheUxp
c3QoKTsKCgkJcHVibGljIGludCBjb3VudGVyOwoKCQlwdWJsaWMgYm9vbGVh biBib29sOwoK
CQlwdWJsaWMgTXlNb2RlbChpbnQgY291bnRlciwgTXlNb2RlbCBwYXJlbnQp IHsKCQkJdGhp
cy5wYXJlbnQgPSBwYXJlbnQ7CgkJCXRoaXMuY291bnRlciA9IGNvdW50ZXI7 CgkJfQoKCQlw
dWJsaWMgU3RyaW5nIHRvU3RyaW5nKCkgewoJCQlTdHJpbmcgcnYgPSAiSXRl bSAiOwoJCQlp
ZiAocGFyZW50ICE9IG51bGwpIHsKCQkJCXJ2ID0gcGFyZW50LnRvU3RyaW5n KCkgKyAiLiI7
CgkJCX0KCgkJCXJ2ICs9IGNvdW50ZXI7CgoJCQlyZXR1cm4gcnY7CgkJfQoJ fQoKfQ==
--------------080903040305090700050508--

Re: Focus traversal and editable table cells [message #320997 is a reply to message #320996]

Thu, 04 October 2007 16:17

Eclipse User

I've added the snippet to our collection.

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 18: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 #321007 is a reply to message #321003]

Thu, 04 October 2007 18:55

Eclipse User

Eric Rizzo schrieb:
> 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'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

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 #321010 is a reply to message #321007]

Thu, 04 October 2007 22: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 #321013 is a reply to message #321010]

Fri, 05 October 2007 01:15

Eclipse User

Eric Rizzo schrieb:
> 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...

1. set a state variable in your LabelProvider when
EditingSupport#getCellEditor is called

2. call Viewer#update(Object,String[]) => your LabelProvider returns
null as an image for the given column

3. reset state variable EditingSupport#setValue()

I think the snippet I provided for you does exactly when you want and
you can use the default CheckBoxCellEditor, not?

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 #321036 is a reply to message #320996]

Fri, 05 October 2007 12: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 12: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 #321038 is a reply to message #321036]

Fri, 05 October 2007 12:12

Eclipse User

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

Tom

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

--
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 #321070 is a reply to message #321038]

Sun, 07 October 2007 22: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
>
>

Re: Focus traversal and editable table cells [message #326780 is a reply to message #320997]

Tue, 01 April 2008 08:47

Eclipse User

Tom Schindl wrote:
> I've added the snippet to our collection.
>
> Tom
>

Thank you for this great snippet. It helped me to enable tabbing over my
CheckBoxCellEditor. Unfortunately I always get a beep-sound (like
Display.beep()) when tabbing over this editor. This also happens with
your snippet. Do you know why this happens?

Thanks,
Matthias

Re: Focus traversal and editable table cells [message #326782 is a reply to message #326780]

Tue, 01 April 2008 08:57

Eclipse User

Could you please file a bug against Platform/UI and prefix the summary
with [Snippets].

Tom

Matthias Schoettle schrieb:
> Tom Schindl wrote:
>> I've added the snippet to our collection.
>>
>> Tom
>>
>
> Thank you for this great snippet. It helped me to enable tabbing over my
> CheckBoxCellEditor. Unfortunately I always get a beep-sound (like
> Display.beep()) when tabbing over this editor. This also happens with
> your snippet. Do you know why this happens?
>
> Thanks,
> Matthias

--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------

Previous Topic:	Workbench event loop stuck after EMF bulk update
Next Topic:	Editor positions

Goto Forum:

-=] Back to Top [=-

Current Time: Wed Mar 19 15:04:39 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter