Home » Eclipse Projects » Nebula » Customization of cell activation strategy
| |
| Re: Customization of cell activation strategy [message #43593 is a reply to message #43562] |
Tue, 20 November 2007 10:59   |
 Andrey Kononenko
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Dear Tom
Thank you very much for your quick and well-grounded answer. Perhaps, I
did not give you accurate description of my needs. Moreover, my needs lay
in jFace classes and Nebula just use s it. So perhaps my question should
be addressed to jFace developer. But I believe my improvement would be
useful in Grid component.
Ive changed the snippet for grid to describe my needs and suggestions.
1. We use single click editor activation, so first mouse DOWN click calls
isEditorActivationEvent (because of it is called from ColumnViewer#
handleMouseDown). An issue is how to start editor by mouse Up event
(which is not handled by default in isEditorActivationEvent), because if
mouseUp event performs in another cell, than editor should not start at
all. Could you share your vision of approach? Our idea is extend
GridTableViewer and add handleMouseUp method very similar to
handleMouseDown (so this method should calculate cell by getCell method,
which has default access).
2. Please use tabbing in my example. As you see, Tab changes a focus and
START editor for next cell. But selection stays in previous cell. This is
the first issue for tabbing. Would you mind to say your oppinion about
this
3. Second issue with tabbing is how change tabbing behavior for NOT
STARTING editoršin the most 'standart' way. My idea about `deactivation
strategy tries to resolve cases like this: describe standard cases which
CLOSE editor.
Thank you in advance
Regards
Andrey
/**
* A simple TreeViewer to demonstrate usage
*
* @author Tom Schindl <tom.schindl@bestsolution.at>
*
*/
public class Snippet026TreeViewerTabEditingForGrid {
public Snippet026TreeViewerTabEditingForGrid(final Shell shell) {
Button b = new Button(shell,SWT.PUSH);
b.setText("Remove column");
// Grid used instead jFace viewer
final GridTableViewer v = new GridTableViewer(shell, SWT.FULL_SELECTION);
v.getGrid().setLinesVisible(true);
v.getGrid().setHeaderVisible(true);
b.addSelectionListener(new SelectionListener() {
public void widgetDefaultSelected(SelectionEvent e) {
}
public void widgetSelected(SelectionEvent e) {
v.getGrid().getColumn(1).dispose();
}
});
// does not available for Grid
//TableViewerFocusCellManager focusCellManager = new
TableViewerFocusCellManager(v,new FocusCellOwnerDrawHighlighter(v));
ColumnViewerEditorActivationStrategy actSupport = new
ColumnViewerEditorActivationStrategy(v) {
protected boolean isEditorActivationEvent(
ColumnViewerEditorActivationEvent event) {
System.out.println("event "+event.eventType);
return event.eventType == ColumnViewerEditorActivationEvent.TRAVERSAL
//mouse click activation!!!
|| event.eventType ==
ColumnViewerEditorActivationEvent.MOUSE_CLICK_SELECTION
|| (event.eventType == ColumnViewerEditorActivationEvent.KEY_PRESSED
&& event.keyCode == SWT.CR)
|| event.eventType == ColumnViewerEditorActivationEvent.PROGRAMMATIC;
}
};
GridViewerEditor.create(v, actSupport,
ColumnViewerEditor.TABBING_HORIZONTAL |
ColumnViewerEditor.TABBING_MOVE_TO_ROW_NEIGHBOR
| ColumnViewerEditor.TABBING_VERTICAL |
ColumnViewerEditor.KEYBOARD_ACTIVATION);
v.getGrid().setCellSelectionEnabled(true);
final TextCellEditor textCellEditor = new TextCellEditor(v.getGrid());
GridViewerColumn column = new GridViewerColumn(v, SWT.NONE);
//code from real snippet
|
|
| | | |
| Re: Customization of cell activation strategy [message #43715 is a reply to message #43684] |
Tue, 20 November 2007 15:53 |
Andrey Kononenko
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Tom
Thank you once more for your very useful solutions and your attention.
>> It a kind of works, a kind of because there seems to be a bug in the
>> Grid-implementation when one sets the selection like this, the new
>> cell is hightlighted but the focus border is not moved. I'm not an
>> expert on Grid's implementation so maybe I have to do some thing
>> different.
> It's not a bug my implementation was wrong:
>
>> protected void updateFocusCell(ViewerCell focusCell,
>> ColumnViewerEditorActivationEvent event) {
>> if (event.eventType ==
>> ColumnViewerEditorActivationEvent.PROGRAMMATIC
>> || event.eventType ==
>> ColumnViewerEditorActivationEvent.TRAVERSAL) {
>> Grid grid = ((Grid)getViewer().getControl());
>> grid.deselectAllCells();
>>
>> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
>> grid.setCellSelection(new
>>
Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>>
>> }
>> }
I've considered a similar solution to yours, but I met some issues:
1. GridViewerEditor has constructor with default access, so it is not
easy to extend it. Could you describe reasons for this access type? or
could you change it to protected?
2. As I understand standard behavior for tabbing for Grid and SWT
STARTS(!) editor for next cell. Nevertheless it seems as not common
solution, e.g. Excel does not start editor by tabbing. So traversal
event works only if editor is activated, but I don't want start editor
in this case. Could your share your ideas about this 'loop'?
Please find answers for your question from other items below:
>> Second issue with tabbing is how change tabbing behavior for NOT
>> STARTING editoršin the most 'standard' way. My idea about
>>'deactivation strategy' tries to resolve cases like this: describe
>> standard cases which CLOSE editor.
>Can you please rephrase this. I'm afraid I can't follow you here.
New GridViewerEditor has parameter ColumnViewerEditorActivationStrategy
which allows describe a strategy to make decision about start editing.
It is very useful for extending Grid without deriving. I've suggested
add a similar strategy for deactivation. It could cover cases with
starting editor, canceling/applying value from editor by some events
etc. Because now a lot of functionality hidden inside code and listeners
do not guarantied for good solution (at least clear and maintainable
solution).
4.>> What do you think about some useful method like
>>ColumnViewer#getCell with default access? Have you considered
> Why do you need this method, log a bug against Platform/UI and prefix
> your summary with [Viewers] and make sure you give us use-case
without > one opening API is hard to push through :-)
I need the method for handle mouse up event at least. But my reason for
asking was behind my needs. Method ColumnViewer#getViewerRow(Point) has
a protected access, but a similar method ColumnViewer#getCell(Point) has
default access. What is the difference between the methods? In my case I
have to copy code from getCell() without any explicit reasons. Perhaps
methods like getCell() could be have protected modifier?
Sorry for disturb you with my issues. Thank you once more for your
efforts. I really appreciate you!
Regards
Andrey
> [...]
>
>> It a kind of works, a kind of because there seems to be a bug in the
>> Grid-implementation when one sets the selection like this, the new
>> cell is hightlighted but the focus border is not moved. I'm not an
>> expert on Grid's implementation so maybe I have to do some thing
>> different.
>>
>
> It's not a bug my implementation was wrong:
>
>> protected void updateFocusCell(ViewerCell focusCell,
>> ColumnViewerEditorActivationEvent event) {
>> if (event.eventType ==
>> ColumnViewerEditorActivationEvent.PROGRAMMATIC
>> || event.eventType ==
>> ColumnViewerEditorActivationEvent.TRAVERSAL) {
>> Grid grid = ((Grid)getViewer().getControl());
>> grid.deselectAllCells();
>>
>> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
>> grid.setCellSelection(new
>> Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>>
>> }
>> }
>
>
>> Tom
>>
>
>
|
|
|
| Re: Customization of cell activation strategy [message #43747 is a reply to message #43715] |
Tue, 20 November 2007 16:42 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Andrey schrieb:
> Tom
>
> Thank you once more for your very useful solutions and your attention.
>
> >> It a kind of works, a kind of because there seems to be a bug in the
> >> Grid-implementation when one sets the selection like this, the new
> >> cell is hightlighted but the focus border is not moved. I'm not an
> >> expert on Grid's implementation so maybe I have to do some thing
> >> different.
> > It's not a bug my implementation was wrong:
> >
> >> protected void updateFocusCell(ViewerCell focusCell,
> >> ColumnViewerEditorActivationEvent event) {
> >> if (event.eventType ==
> >> ColumnViewerEditorActivationEvent.PROGRAMMATIC
> >> || event.eventType ==
> >> ColumnViewerEditorActivationEvent.TRAVERSAL) {
> >> Grid grid = ((Grid)getViewer().getControl());
> >> grid.deselectAllCells();
> >>
> >> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
> >> grid.setCellSelection(new
> >>
> Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>
> >>
> >> }
> >> }
>
> I've considered a similar solution to yours, but I met some issues:
>
> 1. GridViewerEditor has constructor with default access, so it is not
> easy to extend it. Could you describe reasons for this access type? or
> could you change it to protected?
Please log a bug against Nebula and we'll discuss implementing this in
the GridViewerEditor there. The reason why we expose as few API as
possible is that we have to support everything which is protected/public
forever (see http://wiki.eclipse.org/Evolving_Java-based_APIs and
http://wiki.eclipse.org/Evolving_Java-based_APIs_2)
>
> 2. As I understand standard behavior for tabbing for Grid and SWT
> STARTS(!) editor for next cell. Nevertheless it seems as not common
> solution, e.g. Excel does not start editor by tabbing. So traversal
> event works only if editor is activated, but I don't want start editor
> in this case. Could your share your ideas about this 'loop'?
>
What should happen if you hit the Tab-Key? Should the focus simply move
the the next cell?
If this is true does implementing the strategy like this:
> ColumnViewerEditorActivationStrategy actSupport = new ColumnViewerEditorActivationStrategy(v) {
> protected boolean isEditorActivationEvent(
> ColumnViewerEditorActivationEvent event) {
> return /*event.eventType == ColumnViewerEditorActivationEvent.TRAVERSAL
> ||*/ event.eventType == ColumnViewerEditorActivationEvent.MOUSE_DOUBLE_CLICK_SELECTI ON
> || (event.eventType == ColumnViewerEditorActivationEvent.KEY_PRESSED && event.keyCode == SWT.CR)
> || event.eventType == ColumnViewerEditorActivationEvent.PROGRAMMATIC;
> }
> };
does give you this behaviour?
> Please find answers for your question from other items below:
>
> >> Second issue with tabbing is how change tabbing behavior for NOT
> >> STARTING editoršin the most 'standard' way. My idea about
> >>'deactivation strategy' tries to resolve cases like this: describe
> >> standard cases which CLOSE editor.
>
> >Can you please rephrase this. I'm afraid I can't follow you here.
> New GridViewerEditor has parameter ColumnViewerEditorActivationStrategy
> which allows describe a strategy to make decision about start editing.
> It is very useful for extending Grid without deriving. I've suggested
> add a similar strategy for deactivation. It could cover cases with
> starting editor, canceling/applying value from editor by some events
> etc. Because now a lot of functionality hidden inside code and listeners
> do not guarantied for good solution (at least clear and maintainable
> solution).
Please give me an example what such an event could be? Currently the
CellEditor is responsible to define when it wants to apply the value and
it is the right place IMHO.
You can already cancle/apply the editor value programmatically using
ColumnViewer#cancelEditing and ColumnViewer#applyEditorValue() where
applyEditorValue is protected and you should request opening-up for you
in JFace 3.4 (log a bug against Platform/UI) and/or convince Chris that
it is a good idea to provide it as an API-Method in Nebface.
>
> 4.>> What do you think about some useful method like
> >>ColumnViewer#getCell with default access? Have you considered
>
> > Why do you need this method, log a bug against Platform/UI and prefix
> > your summary with [Viewers] and make sure you give us use-case
> without > one opening API is hard to push through :-)
> I need the method for handle mouse up event at least. But my reason for
> asking was behind my needs. Method ColumnViewer#getViewerRow(Point) has
> a protected access, but a similar method ColumnViewer#getCell(Point) has
> default access. What is the difference between the methods? In my case I
> have to copy code from getCell() without any explicit reasons. Perhaps
> methods like getCell() could be have protected modifier?
For reasons see above. I can't remember why we made
ColumnViewer#getViewerRow(Point) and it looks like a bug that we made it
protected but we can't reduce visibility any more this would be an
API-breaking change.
You are right it might be a good use case to open the API, the problem I
see with the cell that is returned from this call has special behaviour
because the underlying ViewerRow might change without notification so it
might make more sense for external customers to that the public method
returns a clone here.
Please log a bug against Platform/UI describing your use case.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
| | |
| Re: Customization of cell activation strategy [message #43996 is a reply to message #43967] |
Wed, 28 November 2007 12:24 |
Eclipse User |
|
|
|
Originally posted by: akn.ciklum.net
Tom,
Thank you very much! It's the great job!
Sorry for delay, I've been on vacation. Now I've create issue (bug) for
access modifier of GridViewerEditor's constructor. It is not critical
issue for now, but I believe its fixing would be simplify extending of
the GridViewerEditor. Thank you in advance.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=211088
Regards
Andrey
> Andrey,
>
> It seems you have yourself not attached to the bug I filed [1]. I wanted
> to inform you that the relevant changes have been made in CVS to allow
> customization of focus behaviour. With introduced a new constant
> (GridViewerEditor#FOCUS_FOLLOWS_EDITOR) you can use to modify the focus
> behaviour.
>
> You *haven't filed any bugs* so I assume with the change from above your
> use case can be supported using JFace/Nebface without subclassing or any
> other hacks (I think about the opening of the
> ColumnViewer#applyEditorValue() here).
>
> Tom
>
> [1]https://bugs.eclipse.org/bugs/show_bug.cgi?id=210833
>
|
|
|
| Re: Customization of cell activation strategy [message #44025 is a reply to message #43562] |
Wed, 28 November 2007 13:21 |
| Eclipse User |
|
|
|
Originally posted by: akn.ciklum.net
Tom
I'd like to detail my question about cell editor activation and multi
cell selection. Is it possible in Grid to use mouseUp event for calling
a cell editor activation strategy in method sEditorActivationEvent(...)?
Details:
handleEditorActivationEvent(...) method is called only during MouseDown
event (in method handleMouseDown(...)). Thus if MOUSE_CLICK_SELECTION
uses for cell editor activation, than it is considered only for
mouseDown event and starts editor by first mouseDown event. If user
wants select several cells by mouse dragging, then first selected cell
will be with started editor.
It is possible override method hookEditingSupport(...) and add
handleMouseUp(...) method (similar to handleMouseDown). Nevertheless
handleMouseDown(...) uses some package access methods (e.g.
getCell(...)), so we need copy this method in our class. This code
doubling is not good in my opinion.
Would you mind to add a customization for this case to chose mouseDown
and MouseUp event? Perhaps, it would be useful for multi cell selection.
What do you think about it?
Thank you in advance.
Regards
Andrey
> Andrey schrieb:
>> Dear colleagues
>>
>> I�ve met some issue with the strategy with mouse event. It works by
>> mouse down event only. Perhaps, it covers most requests, but I need
>> select several cells by mouse dragging (e.g. because of single click
>> editor activation strategy). So I�ve customized the strategy by
>> overriding hookEditingSupport() method for handling mouse up/down and
>
> Is this really needed why are you not simply overloading
>
> ColumnViewerEditorActivationStrategy#isEditorActivationEvent () like
> shown in
> http://wiki.eclipse.org/JFaceSnippets#Snippet026TreeViewerTa bEditing?
>
>> calculating some flag . The flag allows make decision about starting
>> of editor. But it looks like a hack. So I�d like to ask you about some
>> improvement of Grid. Perhaps, it�d be useful for other user of the
>> library.
>>
>> 1. Could you modify the cell activation strategy for any event (not only
>
> Which event beside Mouse and Keyboard do you think is need for
> Activation? You can always force activation by
> ColumnViewer#editElement(Object,int).
>
>> for mouse down event). 2. What do you think about some useful method
>> like ColumnViewer#getCell with default access? Have you considered
>
> Why do you need this method, log a bug against Platform/UI and prefix
> your summary with [Viewers] and make sure you give us use-case without
> one opening API is hard to push through :-)
>
>> asking developer of jface to change its modifier? 3. What do you think
>> about adding some �deactivation strategy� for behavior customization?
>
> What do you want to customize? You can already register as a listener
> and get notified when the editor is deactivated I'm not sure currently
> whether you can veto it.
>
> Tom
>
|
|
| |
| Re: Customization of cell activation strategy [message #44085 is a reply to message #44055] |
Wed, 28 November 2007 16:53 |
| Eclipse User |
|
|
|
Originally posted by: akn.ciklum.net
This is a multi-part message in MIME format.
--------------060005070407070701010903
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Tom
Thank you for your patience and complete answers. I appreciate you for
all suggestions, explanations and great job!
I use newsgroup before filing a bug (as warned in bugzilla) to
understand your reason and opinion for some features and behavior. I'd
like to create some issues only after it.
So I'd like to give you a use-case.
> 1. Dumb question
> ----------------
> Doesn't selecting multiple cells always involves pressing SHIFT or CTRL
> so this could be the indicator for you to cancel the editor activation
> event.
What about mouse dragging? Moreover, please see an attached file and try
to use following use-case for check box.
1. Mouse down on check box.
2. Drag mouse to other column (e.g. on 1st column)
3. Mouse up on other cell.
Expected result: several cells are selected (from the mouseDown to the
mouseUp cells).
Actual result: no selection, check box change its state.
What is your opinion about the use-case? Is it worth to create an
enhancement?
Regards
Andrey
> 2. Access to internal methods
> -----------------------------
> a) File a bug!!!!!!! I'm not the only decision maker there are others
> who have more to say than me and without getting them involved by
> filing bugs against Platform/UI nothing will get done!
>
> b) Use reflection to access them in the meanwhile
>
> 3. Subclassing classes that are not intended to be subclassed
> ------------------------------------------------------------ -
> Is nothing we can stop you from doing but don't blame us if your code
> suddenly breaks in future. We support what we defined as API but after
> that you are on your own
>
> More details below.
>
> Andrey schrieb:
>> Tom
>>
>> I'd like to detail my question about cell editor activation and multi
>> cell selection. Is it possible in Grid to use mouseUp event for
>> calling a cell editor activation strategy in method
>> sEditorActivationEvent(...)?
>
> No.
>
>>
>> Details:
>>
>> handleEditorActivationEvent(...) method is called only during
>> MouseDown event (in method handleMouseDown(...)). Thus if
>> MOUSE_CLICK_SELECTION uses for cell editor activation, than it is
>> considered only for mouseDown event and starts editor by first
>> mouseDown event. If user wants select several cells by mouse dragging,
>> then first selected cell will be with started editor.
>>
>
> Looks like a valid use case.
>
>> It is possible override method hookEditingSupport(...) and add
>> handleMouseUp(...) method (similar to handleMouseDown). Nevertheless
>> handleMouseDown(...) uses some package access methods (e.g.
>> getCell(...)), so we need copy this method in our class. This code
>> doubling is not good in my opinion.
>
> See 2 and 3
>
>>
>> Would you mind to add a customization for this case to chose mouseDown
>> and MouseUp event? Perhaps, it would be useful for multi cell
>> selection. What do you think about it?
>
> See 2b
>
> Tom
>
--------------060005070407070701010903
Content-Type: text/plain;
name="Snippet026TreeViewerTabEditingForGrid.java"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="Snippet026TreeViewerTabEditingForGrid.java"
cGFja2FnZSBvcmcuZWNsaXBzZS5zd3QubmVidWxhLnNuaXBwZXRzLmdyaWQ7 DQoNCmltcG9y
dCBqYXZhLnV0aWwuQXJyYXlMaXN0Ow0KDQppbXBvcnQgb3JnLmVjbGlwc2Uu amZhY2Uudmll
d2Vycy5DZWxsRWRpdG9yOw0KaW1wb3J0IG9yZy5lY2xpcHNlLmpmYWNlLnZp ZXdlcnMuQ29s
dW1uTGFiZWxQcm92aWRlcjsNCmltcG9ydCBvcmcuZWNsaXBzZS5qZmFjZS52 aWV3ZXJzLkNv
bHVtblZpZXdlckVkaXRvcjsNCmltcG9ydCBvcmcuZWNsaXBzZS5qZmFjZS52 aWV3ZXJzLkNv
bHVtblZpZXdlckVkaXRvckFjdGl2YXRpb25TdHJhdGVneTsNCmltcG9ydCBv cmcuZWNsaXBz
ZS5qZmFjZS52aWV3ZXJzLkVkaXRpbmdTdXBwb3J0Ow0KaW1wb3J0IG9yZy5l Y2xpcHNlLmpm
YWNlLnZpZXdlcnMuQ29sdW1uVmlld2VyRWRpdG9yQWN0aXZhdGlvbkV2ZW50 Ow0KaW1wb3J0
IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuSVRyZWVDb250ZW50UHJvdmlk ZXI7DQppbXBv
cnQgb3JnLmVjbGlwc2UuamZhY2Uudmlld2Vycy5UZXh0Q2VsbEVkaXRvcjsN Cg0KaW1wb3J0
IG9yZy5lY2xpcHNlLmpmYWNlLnZpZXdlcnMuVmlld2VyOw0KaW1wb3J0IG9y Zy5lY2xpcHNl
Lm5lYnVsYS5qZmFjZS5ncmlkdmlld2VyLkdyaWRUYWJsZVZpZXdlcjsNCmlt cG9ydCBvcmcu
ZWNsaXBzZS5uZWJ1bGEuamZhY2UuZ3JpZHZpZXdlci5HcmlkVmlld2VyQ29s dW1uOw0KaW1w
b3J0IG9yZy5lY2xpcHNlLm5lYnVsYS5qZmFjZS5ncmlkdmlld2VyLkdyaWRW aWV3ZXJFZGl0
b3I7DQoNCmltcG9ydCBvcmcuZWNsaXBzZS5zd3QuU1dUOw0KaW1wb3J0IG9y Zy5lY2xpcHNl
LnN3dC5ldmVudHMuU2VsZWN0aW9uRXZlbnQ7DQppbXBvcnQgb3JnLmVjbGlw c2Uuc3d0LmV2
ZW50cy5TZWxlY3Rpb25MaXN0ZW5lcjsNCmltcG9ydCBvcmcuZWNsaXBzZS5z d3QubGF5b3V0
LkZpbGxMYXlvdXQ7DQppbXBvcnQgb3JnLmVjbGlwc2Uuc3d0LndpZGdldHMu QnV0dG9uOw0K
aW1wb3J0IG9yZy5lY2xpcHNlLnN3dC53aWRnZXRzLkRpc3BsYXk7DQppbXBv cnQgb3JnLmVj
bGlwc2Uuc3d0LndpZGdldHMuU2hlbGw7DQoNCi8qKg0KICogQSBzaW1wbGUg VHJlZVZpZXdl
ciB0byBkZW1vbnN0cmF0ZSB1c2FnZQ0KICogDQogKiBAYXV0aG9yIFRvbSBT Y2hpbmRsIDx0
b20uc2NoaW5kbEBiZXN0c29sdXRpb24uYXQ+DQogKiANCiAqLw0KcHVibGlj IGNsYXNzIFNu
aXBwZXQwMjZUcmVlVmlld2VyVGFiRWRpdGluZ0ZvckdyaWQgew0KCXB1Ymxp YyBTbmlwcGV0
MDI2VHJlZVZpZXdlclRhYkVkaXRpbmdGb3JHcmlkKGZpbmFsIFNoZWxsIHNo ZWxsKSB7DQoJ
CUJ1dHRvbiBiID0gbmV3IEJ1dHRvbihzaGVsbCxTV1QuUFVTSCk7DQoJCWIu c2V0VGV4dCgi
UmVtb3ZlIGNvbHVtbiIpOw0KCQkvLyBHcmlkIHVzZWQgaW5zdGVhZCBqRmFj ZSB2aWV3ZXIN
CgkJZmluYWwgR3JpZFRhYmxlVmlld2VyIHYgPSBuZXcgR3JpZFRhYmxlVmll d2VyKHNoZWxs
LCBTV1QuRlVMTF9TRUxFQ1RJT04pOw0KCQl2LmdldEdyaWQoKS5zZXRMaW5l c1Zpc2libGUo
dHJ1ZSk7DQoJCXYuZ2V0R3JpZCgpLnNldEhlYWRlclZpc2libGUodHJ1ZSk7 IA0KCQliLmFk
ZFNlbGVjdGlvbkxpc3RlbmVyKG5ldyBTZWxlY3Rpb25MaXN0ZW5lcigpIHsN Cg0KCQkJcHVi
bGljIHZvaWQgd2lkZ2V0RGVmYXVsdFNlbGVjdGVkKFNlbGVjdGlvbkV2ZW50 IGUpIHsNCgkJ
CQkNCgkJCX0NCg0KCQkJcHVibGljIHZvaWQgd2lkZ2V0U2VsZWN0ZWQoU2Vs ZWN0aW9uRXZl
bnQgZSkgew0KCQkJCXYuZ2V0R3JpZCgpLmdldENvbHVtbigxKS5kaXNwb3Nl KCk7DQoJCQl9
DQoJCQkNCgkJfSk7DQoJCQkJIA0KCQkvLyBkb2VzIG5vdCBhdmFpbGFibGUg Zm9yIEdyaWQg
DQoJCS8vVGFibGVWaWV3ZXJGb2N1c0NlbGxNYW5hZ2VyIGZvY3VzQ2VsbE1h bmFnZXIgPSBu
ZXcgVGFibGVWaWV3ZXJGb2N1c0NlbGxNYW5hZ2VyKHYsbmV3IEZvY3VzQ2Vs bE93bmVyRHJh
d0hpZ2hsaWdodGVyKHYpKTsNCgkJQ29sdW1uVmlld2VyRWRpdG9yQWN0aXZh dGlvblN0cmF0
ZWd5IGFjdFN1cHBvcnQgPSBuZXcgQ29sdW1uVmlld2VyRWRpdG9yQWN0aXZh dGlvblN0cmF0
ZWd5KHYpIHsNCgkJCXByb3RlY3RlZCBib29sZWFuIGlzRWRpdG9yQWN0aXZh dGlvbkV2ZW50
KA0KCQkJCQlDb2x1bW5WaWV3ZXJFZGl0b3JBY3RpdmF0aW9uRXZlbnQgZXZl bnQpIHsNCgkJ
CQlTeXN0ZW0ub3V0LnByaW50bG4oImV2ZW50ICIrZXZlbnQuZXZlbnRUeXBl KTsNCgkJCQly
ZXR1cm4gZXZlbnQuZXZlbnRUeXBlID09IENvbHVtblZpZXdlckVkaXRvckFj dGl2YXRpb25F
dmVudC5UUkFWRVJTQUwNCgkJCQkJCS8vbW91c2UgY2xpY2sgYWN0aXZhdGlv biEhIQ0KCQkJ
CQkJfHwgZXZlbnQuZXZlbnRUeXBlID09IENvbHVtblZpZXdlckVkaXRvckFj dGl2YXRpb25F
dmVudC5NT1VTRV9DTElDS19TRUxFQ1RJT04NCgkJCQkJCXx8IChldmVudC5l dmVudFR5cGUg
PT0gQ29sdW1uVmlld2VyRWRpdG9yQWN0aXZhdGlvbkV2ZW50LktFWV9QUkVT U0VEICYmIGV2
ZW50LmtleUNvZGUgPT0gU1dULkNSKQ0KCQkJCQkJfHwgZXZlbnQuZXZlbnRU eXBlID09IENv
bHVtblZpZXdlckVkaXRvckFjdGl2YXRpb25FdmVudC5QUk9HUkFNTUFUSUM7 DQoJCQl9DQoJ
CX07DQoJCQ0KCQkNCgkJR3JpZFZpZXdlckVkaXRvci5jcmVhdGUodiwgYWN0 U3VwcG9ydCwg
Q29sdW1uVmlld2VyRWRpdG9yLlRBQkJJTkdfSE9SSVpPTlRBTCB8IENvbHVt blZpZXdlckVk
aXRvci5UQUJCSU5HX01PVkVfVE9fUk9XX05FSUdIQk9SDQoJCSAgICAgICAg fCBDb2x1bW5W
aWV3ZXJFZGl0b3IuVEFCQklOR19WRVJUSUNBTCB8IENvbHVtblZpZXdlckVk aXRvci5LRVlC
T0FSRF9BQ1RJVkFUSU9OKTsNCgkJdi5nZXRHcmlkKCkuc2V0Q2VsbFNlbGVj dGlvbkVuYWJs
ZWQodHJ1ZSk7DQoJCQ0KCQlmaW5hbCBUZXh0Q2VsbEVkaXRvciB0ZXh0Q2Vs bEVkaXRvciA9
IG5ldyBUZXh0Q2VsbEVkaXRvcih2LmdldEdyaWQoKSk7DQoNCgkJR3JpZFZp ZXdlckNvbHVt
biBjb2x1bW4gPSBuZXcgR3JpZFZpZXdlckNvbHVtbih2LCBTV1QuTk9ORSk7 DQoJCWNvbHVt
bi5nZXRDb2x1bW4oKS5zZXRXaWR0aCg3MCk7DQoJCWNvbHVtbi5nZXRDb2x1 bW4oKS5zZXRN
b3ZlYWJsZSh0cnVlKTsNCgkJY29sdW1uLmdldENvbHVtbigpLnNldFRleHQo IkNvbHVtbiAx
Iik7DQoJCWNvbHVtbi5zZXRMYWJlbFByb3ZpZGVyKG5ldyBDb2x1bW5MYWJl bFByb3ZpZGVy
KCkgew0KDQoJCQlwdWJsaWMgU3RyaW5nIGdldFRleHQoT2JqZWN0IGVsZW1l bnQpIHsNCgkJ
CQlyZXR1cm4gIkNvbHVtbiAxID0+ICIgKyBlbGVtZW50LnRvU3RyaW5nKCk7 DQoJCQl9DQoN
CgkJfSk7DQoJCWNvbHVtbi5zZXRFZGl0aW5nU3VwcG9ydChuZXcgRWRpdGlu Z1N1cHBvcnQo
dikgew0KCQkJcHJvdGVjdGVkIGJvb2xlYW4gY2FuRWRpdChPYmplY3QgZWxl bWVudCkgew0K
CQkJCXJldHVybiBmYWxzZTsNCgkJCX0NCg0KCQkJcHJvdGVjdGVkIENlbGxF ZGl0b3IgZ2V0
Q2VsbEVkaXRvcihPYmplY3QgZWxlbWVudCkgew0KCQkJCXJldHVybiB0ZXh0 Q2VsbEVkaXRv
cjsNCgkJCX0NCg0KCQkJcHJvdGVjdGVkIE9iamVjdCBnZXRWYWx1ZShPYmpl Y3QgZWxlbWVu
dCkgew0KCQkJCXJldHVybiAoKE15TW9kZWwpIGVsZW1lbnQpLmNvdW50ZXIg KyAiIjsNCgkJ
CX0NCg0KCQkJcHJvdGVjdGVkIHZvaWQgc2V0VmFsdWUoT2JqZWN0IGVsZW1l bnQsIE9iamVj
dCB2YWx1ZSkgew0KCQkJCSgoTXlNb2RlbCkgZWxlbWVudCkuY291bnRlciA9 IEludGVnZXIN
CgkJCQkJCS5wYXJzZUludCh2YWx1ZS50b1N0cmluZygpKTsNCgkJCQl2LnVw ZGF0ZShlbGVt
ZW50LCBudWxsKTsNCgkJCX0NCgkJfSk7DQoNCgkJY29sdW1uID0gbmV3IEdy aWRWaWV3ZXJD
b2x1bW4odiwgU1dULk5PTkUpOw0KCQljb2x1bW4uZ2V0Q29sdW1uKCkuc2V0 V2lkdGgoNzAp
Ow0KCQljb2x1bW4uZ2V0Q29sdW1uKCkuc2V0TW92ZWFibGUodHJ1ZSk7DQoJ CWNvbHVtbi5n
ZXRDb2x1bW4oKS5zZXRUZXh0KCJDb2x1bW4gMiIpOw0KCQljb2x1bW4uc2V0 TGFiZWxQcm92
aWRlcihuZXcgQ29sdW1uTGFiZWxQcm92aWRlcigpIHsNCg0KCQkJcHVibGlj IFN0cmluZyBn
ZXRUZXh0KE9iamVjdCBlbGVtZW50KSB7DQoJCQkJcmV0dXJuICJDb2x1bW4g MiA9PiAiICsg
ZWxlbWVudC50b1N0cmluZygpOw0KCQkJfQ0KDQoJCX0pOw0KCQljb2x1bW4u c2V0RWRpdGlu
Z1N1cHBvcnQobmV3IEVkaXRpbmdTdXBwb3J0KHYpIHsNCgkJCXByb3RlY3Rl ZCBib29sZWFu
IGNhbkVkaXQoT2JqZWN0IGVsZW1lbnQpIHsNCgkJCQlyZXR1cm4gdHJ1ZTsN CgkJCX0NCg0K
CQkJcHJvdGVjdGVkIENlbGxFZGl0b3IgZ2V0Q2VsbEVkaXRvcihPYmplY3Qg ZWxlbWVudCkg
ew0KCQkJCXJldHVybiB0ZXh0Q2VsbEVkaXRvcjsNCgkJCX0NCg0KCQkJcHJv dGVjdGVkIE9i
amVjdCBnZXRWYWx1ZShPYmplY3QgZWxlbWVudCkgew0KCQkJCXJldHVybiAo KE15TW9kZWwp
IGVsZW1lbnQpLmNvdW50ZXIgKyAiIjsNCgkJCX0NCg0KCQkJcHJvdGVjdGVk IHZvaWQgc2V0
VmFsdWUoT2JqZWN0IGVsZW1lbnQsIE9iamVjdCB2YWx1ZSkgew0KCQkJCSgo TXlNb2RlbCkg
ZWxlbWVudCkuY291bnRlciA9IEludGVnZXINCgkJCQkJCS5wYXJzZUludCh2 YWx1ZS50b1N0
cmluZygpKTsNCgkJCQl2LnVwZGF0ZShlbGVtZW50LCBudWxsKTsNCgkJCX0N CgkJfSk7DQoJ
CQ0KCQljb2x1bW4gPSBuZXcgR3JpZFZpZXdlckNvbHVtbih2LCBTV1QuTk9O RSk7DQoJCWNv
bHVtbi5nZXRDb2x1bW4oKS5zZXRXaWR0aCgxMDApOw0KCQljb2x1bW4uZ2V0 Q29sdW1uKCku
c2V0TW92ZWFibGUodHJ1ZSk7DQoJCWNvbHVtbi5nZXRDb2x1bW4oKS5zZXRU ZXh0KCJDb2x1
bW4gMyIpOw0KCQljb2x1bW4uc2V0TGFiZWxQcm92aWRlcihuZXcgQ29sdW1u TGFiZWxQcm92
aWRlcigpIHsNCg0KCQkJcHVibGljIFN0cmluZyBnZXRUZXh0KE9iamVjdCBl bGVtZW50KSB7
DQoJCQkJcmV0dXJuICJDb2x1bW4gMyA9PiAiICsgZWxlbWVudC50b1N0cmlu ZygpOw0KCQkJ
fQ0KDQoJCX0pOw0KCQljb2x1bW4uc2V0RWRpdGluZ1N1cHBvcnQobmV3IEVk aXRpbmdTdXBw
b3J0KHYpIHsNCgkJCXByb3RlY3RlZCBib29sZWFuIGNhbkVkaXQoT2JqZWN0 IGVsZW1lbnQp
IHsNCgkJCQlyZXR1cm4gdHJ1ZTsNCgkJCX0NCg0KCQkJcHJvdGVjdGVkIENl bGxFZGl0b3Ig
Z2V0Q2VsbEVkaXRvcihPYmplY3QgZWxlbWVudCkgew0KCQkJCXJldHVybiB0 ZXh0Q2VsbEVk
aXRvcjsNCgkJCX0NCg0KCQkJcHJvdGVjdGVkIE9iamVjdCBnZXRWYWx1ZShP YmplY3QgZWxl
bWVudCkgew0KCQkJCXJldHVybiAoKE15TW9kZWwpIGVsZW1lbnQpLmNvdW50 ZXIgKyAiIjsN
CgkJCX0NCg0KCQkJcHJvdGVjdGVkIHZvaWQgc2V0VmFsdWUoT2JqZWN0IGVs ZW1lbnQsIE9i
amVjdCB2YWx1ZSkgew0KCQkJCSgoTXlNb2RlbCkgZWxlbWVudCkuY291bnRl ciA9IEludGVn
ZXINCgkJCQkJCS5wYXJzZUludCh2YWx1ZS50b1N0cmluZygpKTsNCgkJCQl2 LnVwZGF0ZShl
bGVtZW50LCBudWxsKTsNCgkJCX0NCgkJfSk7DQoJCQ0KCQljb2x1bW4gPSBu ZXcgR3JpZFZp
ZXdlckNvbHVtbih2LCBTV1QuQ0hFQ0sgfCBTV1QuQ0VOVEVSKTsNCiAgICBj b2x1bW4uZ2V0
Q29sdW1uKCkuc2V0V2lkdGgoMTAwKTsNCiAgICBjb2x1bW4uZ2V0Q29sdW1u KCkuc2V0TW92
ZWFibGUodHJ1ZSk7DQogICAgY29sdW1uLmdldENvbHVtbigpLnNldFRleHQo IkNvbHVtbiA0
Iik7DQogICAgY29sdW1uLnNldExhYmVsUHJvdmlkZXIobmV3IENvbHVtbkxh YmVsUHJvdmlk
ZXIoKSB7DQoNCiAgICAgIHB1YmxpYyBTdHJpbmcgZ2V0VGV4dChPYmplY3Qg ZWxlbWVudCkg
ew0KICAgICAgICByZXR1cm4gbnVsbDsNCiAgICAgIH0NCg0KICAgIH0pOw0K CQkNCgkJdi5z
ZXRDb250ZW50UHJvdmlkZXIobmV3IE15Q29udGVudFByb3ZpZGVyKCkpOw0K DQoJCXYuc2V0
SW5wdXQoY3JlYXRlTW9kZWwoKSk7DQoJfQ0KDQoJcHJpdmF0ZSBNeU1vZGVs IGNyZWF0ZU1v
ZGVsKCkgew0KDQoJCU15TW9kZWwgcm9vdCA9IG5ldyBNeU1vZGVsKDAsIG51 bGwpOw0KCQly
b290LmNvdW50ZXIgPSAwOw0KDQoJCU15TW9kZWwgdG1wOw0KCQlNeU1vZGVs IHN1Ykl0ZW07
DQoJCWZvciAoaW50IGkgPSAxOyBpIDwgMTA7IGkrKykgew0KCQkJdG1wID0g bmV3IE15TW9k
ZWwoaSwgcm9vdCk7DQoJCQlyb290LmNoaWxkLmFkZCh0bXApOw0KCQkJZm9y IChpbnQgaiA9
IDE7IGogPCBpOyBqKyspIHsNCgkJCQlzdWJJdGVtID0gbmV3IE15TW9kZWwo aiwgdG1wKTsN
CgkJCQlzdWJJdGVtLmNoaWxkLmFkZChuZXcgTXlNb2RlbChqICogMTAwLCBz dWJJdGVtKSk7
DQoJCQkJdG1wLmNoaWxkLmFkZChzdWJJdGVtKTsNCgkJCX0NCgkJfQ0KDQoJ CXJldHVybiBy
b290Ow0KCX0NCg0KCXB1YmxpYyBzdGF0aWMgdm9pZCBtYWluKFN0cmluZ1td IGFyZ3MpIHsN
CgkJRGlzcGxheSBkaXNwbGF5ID0gbmV3IERpc3BsYXkoKTsNCgkJU2hlbGwg c2hlbGwgPSBu
ZXcgU2hlbGwoZGlzcGxheSk7DQoJCXNoZWxsLnNldExheW91dChuZXcgRmls bExheW91dCgp
KTsNCgkJbmV3IFNuaXBwZXQwMjZUcmVlVmlld2VyVGFiRWRpdGluZ0Zvckdy aWQoc2hlbGwp
Ow0KCQlzaGVsbC5vcGVuKCk7DQoNCgkJd2hpbGUgKCFzaGVsbC5pc0Rpc3Bv c2VkKCkpIHsN
CgkJCWlmICghZGlzcGxheS5yZWFkQW5kRGlzcGF0Y2goKSkNCgkJCQlkaXNw bGF5LnNsZWVw
KCk7DQoJCX0NCg0KCQlkaXNwbGF5LmRpc3Bvc2UoKTsNCgl9DQoNCglwcml2 YXRlIGNsYXNz
IE15Q29udGVudFByb3ZpZGVyIGltcGxlbWVudHMgSVRyZWVDb250ZW50UHJv dmlkZXIgew0K
DQoJCXB1YmxpYyBPYmplY3RbXSBnZXRFbGVtZW50cyhPYmplY3QgaW5wdXRF bGVtZW50KSB7
DQoJCQlyZXR1cm4gKChNeU1vZGVsKSBpbnB1dEVsZW1lbnQpLmNoaWxkLnRv QXJyYXkoKTsN
CgkJfQ0KDQoJCXB1YmxpYyB2b2lkIGRpc3Bvc2UoKSB7DQoJCX0NCg0KCQlw dWJsaWMgdm9p
ZCBpbnB1dENoYW5nZWQoVmlld2VyIHZpZXdlciwgT2JqZWN0IG9sZElucHV0 LCBPYmplY3Qg
bmV3SW5wdXQpIHsNCgkJfQ0KDQoJCXB1YmxpYyBPYmplY3RbXSBnZXRDaGls ZHJlbihPYmpl
Y3QgcGFyZW50RWxlbWVudCkgew0KCQkJcmV0dXJuIGdldEVsZW1lbnRzKHBh cmVudEVsZW1l
bnQpOw0KCQl9DQoNCgkJcHVibGljIE9iamVjdCBnZXRQYXJlbnQoT2JqZWN0 IGVsZW1lbnQp
IHsNCgkJCWlmIChlbGVtZW50ID09IG51bGwpIHsNCgkJCQlyZXR1cm4gbnVs bDsNCgkJCX0N
CgkJCXJldHVybiAoKE15TW9kZWwpIGVsZW1lbnQpLnBhcmVudDsNCgkJfQ0K DQoJCXB1Ymxp
YyBib29sZWFuIGhhc0NoaWxkcmVuKE9iamVjdCBlbGVtZW50KSB7DQoJCQly ZXR1cm4gKChN
eU1vZGVsKSBlbGVtZW50KS5jaGlsZC5zaXplKCkgPiAwOw0KCQl9DQoNCgl9 DQoNCglwdWJs
aWMgY2xhc3MgTXlNb2RlbCB7DQoJCXB1YmxpYyBNeU1vZGVsIHBhcmVudDsN Cg0KCQlwdWJs
aWMgQXJyYXlMaXN0IGNoaWxkID0gbmV3IEFycmF5TGlzdCgpOw0KDQoJCXB1 YmxpYyBpbnQg
Y291bnRlcjsNCg0KCQlwdWJsaWMgTXlNb2RlbChpbnQgY291bnRlciwgTXlN b2RlbCBwYXJl
bnQpIHsNCgkJCXRoaXMucGFyZW50ID0gcGFyZW50Ow0KCQkJdGhpcy5jb3Vu dGVyID0gY291
bnRlcjsNCgkJfQ0KDQoJCXB1YmxpYyBTdHJpbmcgdG9TdHJpbmcoKSB7DQoJ CQlTdHJpbmcg
cnYgPSAiSXRlbSAiOw0KCQkJaWYgKHBhcmVudCAhPSBudWxsKSB7DQoJCQkJ cnYgPSBwYXJl
bnQudG9TdHJpbmcoKSArICIuIjsNCgkJCX0NCg0KCQkJcnYgKz0gY291bnRl cjsNCg0KCQkJ
cmV0dXJuIHJ2Ow0KCQl9DQoJfQ0KDQp9DQoNCg==
--------------060005070407070701010903--
|
|
| | |
| Re: Customization of cell activation strategy [message #586494 is a reply to message #43562] |
Tue, 20 November 2007 10:59 |
Andrey Kononenko
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Dear Tom
Thank you very much for your quick and well-grounded answer. Perhaps, I
did not give you accurate description of my needs. Moreover, my needs lay
in jFace classes and Nebula just use s it. So perhaps my question should
be addressed to jFace developer. But I believe my improvement would be
useful in Grid component.
Ive changed the snippet for grid to describe my needs and suggestions.
1. We use single click editor activation, so first mouse DOWN click calls
isEditorActivationEvent (because of it is called from ColumnViewer#
handleMouseDown). An issue is how to start editor by mouse Up event
(which is not handled by default in isEditorActivationEvent), because if
mouseUp event performs in another cell, than editor should not start at
all. Could you share your vision of approach? Our idea is extend
GridTableViewer and add handleMouseUp method very similar to
handleMouseDown (so this method should calculate cell by getCell method,
which has default access).
2. Please use tabbing in my example. As you see, Tab changes a focus and
START editor for next cell. But selection stays in previous cell. This is
the first issue for tabbing. Would you mind to say your oppinion about
this
3. Second issue with tabbing is how change tabbing behavior for NOT
STARTING editoršin the most 'standart' way. My idea about `deactivation
strategy tries to resolve cases like this: describe standard cases which
CLOSE editor.
Thank you in advance
Regards
Andrey
/**
* A simple TreeViewer to demonstrate usage
*
* @author Tom Schindl <tom.schindl@bestsolution.at>
*
*/
public class Snippet026TreeViewerTabEditingForGrid {
public Snippet026TreeViewerTabEditingForGrid(final Shell shell) {
Button b = new Button(shell,SWT.PUSH);
b.setText("Remove column");
// Grid used instead jFace viewer
final GridTableViewer v = new GridTableViewer(shell, SWT.FULL_SELECTION);
v.getGrid().setLinesVisible(true);
v.getGrid().setHeaderVisible(true);
b.addSelectionListener(new SelectionListener() {
public void widgetDefaultSelected(SelectionEvent e) {
}
public void widgetSelected(SelectionEvent e) {
v.getGrid().getColumn(1).dispose();
}
});
// does not available for Grid
//TableViewerFocusCellManager focusCellManager = new
TableViewerFocusCellManager(v,new FocusCellOwnerDrawHighlighter(v));
ColumnViewerEditorActivationStrategy actSupport = new
ColumnViewerEditorActivationStrategy(v) {
protected boolean isEditorActivationEvent(
ColumnViewerEditorActivationEvent event) {
System.out.println("event "+event.eventType);
return event.eventType == ColumnViewerEditorActivationEvent.TRAVERSAL
//mouse click activation!!!
|| event.eventType ==
ColumnViewerEditorActivationEvent.MOUSE_CLICK_SELECTION
|| (event.eventType == ColumnViewerEditorActivationEvent.KEY_PRESSED
&& event.keyCode == SWT.CR)
|| event.eventType == ColumnViewerEditorActivationEvent.PROGRAMMATIC;
}
};
GridViewerEditor.create(v, actSupport,
ColumnViewerEditor.TABBING_HORIZONTAL |
ColumnViewerEditor.TABBING_MOVE_TO_ROW_NEIGHBOR
| ColumnViewerEditor.TABBING_VERTICAL |
ColumnViewerEditor.KEYBOARD_ACTIVATION);
v.getGrid().setCellSelectionEnabled(true);
final TextCellEditor textCellEditor = new TextCellEditor(v.getGrid());
GridViewerColumn column = new GridViewerColumn(v, SWT.NONE);
//code from real snippet
|
|
| | | |
| Re: Customization of cell activation strategy [message #586532 is a reply to message #43684] |
Tue, 20 November 2007 15:53 |
Andrey Kononenko
Messages: 11
Registered: July 2009 |
Junior Member |
|
|
Tom
Thank you once more for your very useful solutions and your attention.
>> It a kind of works, a kind of because there seems to be a bug in the
>> Grid-implementation when one sets the selection like this, the new
>> cell is hightlighted but the focus border is not moved. I'm not an
>> expert on Grid's implementation so maybe I have to do some thing
>> different.
> It's not a bug my implementation was wrong:
>
>> protected void updateFocusCell(ViewerCell focusCell,
>> ColumnViewerEditorActivationEvent event) {
>> if (event.eventType ==
>> ColumnViewerEditorActivationEvent.PROGRAMMATIC
>> || event.eventType ==
>> ColumnViewerEditorActivationEvent.TRAVERSAL) {
>> Grid grid = ((Grid)getViewer().getControl());
>> grid.deselectAllCells();
>>
>> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
>> grid.setCellSelection(new
>>
Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>>
>> }
>> }
I've considered a similar solution to yours, but I met some issues:
1. GridViewerEditor has constructor with default access, so it is not
easy to extend it. Could you describe reasons for this access type? or
could you change it to protected?
2. As I understand standard behavior for tabbing for Grid and SWT
STARTS(!) editor for next cell. Nevertheless it seems as not common
solution, e.g. Excel does not start editor by tabbing. So traversal
event works only if editor is activated, but I don't want start editor
in this case. Could your share your ideas about this 'loop'?
Please find answers for your question from other items below:
>> Second issue with tabbing is how change tabbing behavior for NOT
>> STARTING editoršin the most 'standard' way. My idea about
>>'deactivation strategy' tries to resolve cases like this: describe
>> standard cases which CLOSE editor.
>Can you please rephrase this. I'm afraid I can't follow you here.
New GridViewerEditor has parameter ColumnViewerEditorActivationStrategy
which allows describe a strategy to make decision about start editing.
It is very useful for extending Grid without deriving. I've suggested
add a similar strategy for deactivation. It could cover cases with
starting editor, canceling/applying value from editor by some events
etc. Because now a lot of functionality hidden inside code and listeners
do not guarantied for good solution (at least clear and maintainable
solution).
4.>> What do you think about some useful method like
>>ColumnViewer#getCell with default access? Have you considered
> Why do you need this method, log a bug against Platform/UI and prefix
> your summary with [Viewers] and make sure you give us use-case
without > one opening API is hard to push through :-)
I need the method for handle mouse up event at least. But my reason for
asking was behind my needs. Method ColumnViewer#getViewerRow(Point) has
a protected access, but a similar method ColumnViewer#getCell(Point) has
default access. What is the difference between the methods? In my case I
have to copy code from getCell() without any explicit reasons. Perhaps
methods like getCell() could be have protected modifier?
Sorry for disturb you with my issues. Thank you once more for your
efforts. I really appreciate you!
Regards
Andrey
> [...]
>
>> It a kind of works, a kind of because there seems to be a bug in the
>> Grid-implementation when one sets the selection like this, the new
>> cell is hightlighted but the focus border is not moved. I'm not an
>> expert on Grid's implementation so maybe I have to do some thing
>> different.
>>
>
> It's not a bug my implementation was wrong:
>
>> protected void updateFocusCell(ViewerCell focusCell,
>> ColumnViewerEditorActivationEvent event) {
>> if (event.eventType ==
>> ColumnViewerEditorActivationEvent.PROGRAMMATIC
>> || event.eventType ==
>> ColumnViewerEditorActivationEvent.TRAVERSAL) {
>> Grid grid = ((Grid)getViewer().getControl());
>> grid.deselectAllCells();
>>
>> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
>> grid.setCellSelection(new
>> Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>>
>> }
>> }
>
>
>> Tom
>>
>
>
|
|
|
| Re: Customization of cell activation strategy [message #586543 is a reply to message #43715] |
Tue, 20 November 2007 16:42 |
Thomas Schindl
Messages: 6651
Registered: July 2009 |
Senior Member |
|
|
Andrey schrieb:
> Tom
>
> Thank you once more for your very useful solutions and your attention.
>
> >> It a kind of works, a kind of because there seems to be a bug in the
> >> Grid-implementation when one sets the selection like this, the new
> >> cell is hightlighted but the focus border is not moved. I'm not an
> >> expert on Grid's implementation so maybe I have to do some thing
> >> different.
> > It's not a bug my implementation was wrong:
> >
> >> protected void updateFocusCell(ViewerCell focusCell,
> >> ColumnViewerEditorActivationEvent event) {
> >> if (event.eventType ==
> >> ColumnViewerEditorActivationEvent.PROGRAMMATIC
> >> || event.eventType ==
> >> ColumnViewerEditorActivationEvent.TRAVERSAL) {
> >> Grid grid = ((Grid)getViewer().getControl());
> >> grid.deselectAllCells();
> >>
> >> grid.setFocusColumn(grid.getColumn(focusCell.getColumnIndex( )));
> >> grid.setCellSelection(new
> >>
> Point(focusCell.getColumnIndex(),grid.indexOf((GridItem)focu sCell.getItem())));
>
> >>
> >> }
> >> }
>
> I've considered a similar solution to yours, but I met some issues:
>
> 1. GridViewerEditor has constructor with default access, so it is not
> easy to extend it. Could you describe reasons for this access type? or
> could you change it to protected?
Please log a bug against Nebula and we'll discuss implementing this in
the GridViewerEditor there. The reason why we expose as few API as
possible is that we have to support everything which is protected/public
forever (see http://wiki.eclipse.org/Evolving_Java-based_APIs and
http://wiki.eclipse.org/Evolving_Java-based_APIs_2)
>
> 2. As I understand standard behavior for tabbing for Grid and SWT
> STARTS(!) editor for next cell. Nevertheless it seems as not common
> solution, e.g. Excel does not start editor by tabbing. So traversal
> event works only if editor is activated, but I don't want start editor
> in this case. Could your share your ideas about this 'loop'?
>
What should happen if you hit the Tab-Key? Should the focus simply move
the the next cell?
If this is true does implementing the strategy like this:
> ColumnViewerEditorActivationStrategy actSupport = new ColumnViewerEditorActivationStrategy(v) {
> protected boolean isEditorActivationEvent(
> ColumnViewerEditorActivationEvent event) {
> return /*event.eventType == ColumnViewerEditorActivationEvent.TRAVERSAL
> ||*/ event.eventType == ColumnViewerEditorActivationEvent.MOUSE_DOUBLE_CLICK_SELECTI ON
> || (event.eventType == ColumnViewerEditorActivationEvent.KEY_PRESSED && event.keyCode == SWT.CR)
> || event.eventType == ColumnViewerEditorActivationEvent.PROGRAMMATIC;
> }
> };
does give you this behaviour?
> Please find answers for your question from other items below:
>
> >> Second issue with tabbing is how change tabbing behavior for NOT
> >> STARTING editoršin the most 'standard' way. My idea about
> >>'deactivation strategy' tries to resolve cases like this: describe
> >> standard cases which CLOSE editor.
>
> >Can you please rephrase this. I'm afraid I can't follow you here.
> New GridViewerEditor has parameter ColumnViewerEditorActivationStrategy
> which allows describe a strategy to make decision about start editing.
> It is very useful for extending Grid without deriving. I've suggested
> add a similar strategy for deactivation. It could cover cases with
> starting editor, canceling/applying value from editor by some events
> etc. Because now a lot of functionality hidden inside code and listeners
> do not guarantied for good solution (at least clear and maintainable
> solution).
Please give me an example what such an event could be? Currently the
CellEditor is responsible to define when it wants to apply the value and
it is the right place IMHO.
You can already cancle/apply the editor value programmatically using
ColumnViewer#cancelEditing and ColumnViewer#applyEditorValue() where
applyEditorValue is protected and you should request opening-up for you
in JFace 3.4 (log a bug against Platform/UI) and/or convince Chris that
it is a good idea to provide it as an API-Method in Nebface.
>
> 4.>> What do you think about some useful method like
> >>ColumnViewer#getCell with default access? Have you considered
>
> > Why do you need this method, log a bug against Platform/UI and prefix
> > your summary with [Viewers] and make sure you give us use-case
> without > one opening API is hard to push through :-)
> I need the method for handle mouse up event at least. But my reason for
> asking was behind my needs. Method ColumnViewer#getViewerRow(Point) has
> a protected access, but a similar method ColumnViewer#getCell(Point) has
> default access. What is the difference between the methods? In my case I
> have to copy code from getCell() without any explicit reasons. Perhaps
> methods like getCell() could be have protected modifier?
For reasons see above. I can't remember why we made
ColumnViewer#getViewerRow(Point) and it looks like a bug that we made it
protected but we can't reduce visibility any more this would be an
API-breaking change.
You are right it might be a good use case to open the API, the problem I
see with the cell that is returned from this call has special behaviour
because the underlying ViewerRow might change without notification so it
might make more sense for external customers to that the public method
returns a clone here.
Please log a bug against Platform/UI describing your use case.
Tom
--
B e s t S o l u t i o n . at
------------------------------------------------------------ --------
Tom Schindl JFace-Committer
------------------------------------------------------------ --------
|
|
| | | |
| Re: Customization of cell activation strategy [message #586666 is a reply to message #43562] |
Wed, 28 November 2007 13:21 |
Andrey
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Tom
I'd like to detail my question about cell editor activation and multi
cell selection. Is it possible in Grid to use mouseUp event for calling
a cell editor activation strategy in method sEditorActivationEvent(...)?
Details:
handleEditorActivationEvent(...) method is called only during MouseDown
event (in method handleMouseDown(...)). Thus if MOUSE_CLICK_SELECTION
uses for cell editor activation, than it is considered only for
mouseDown event and starts editor by first mouseDown event. If user
wants select several cells by mouse dragging, then first selected cell
will be with started editor.
It is possible override method hookEditingSupport(...) and add
handleMouseUp(...) method (similar to handleMouseDown). Nevertheless
handleMouseDown(...) uses some package access methods (e.g.
getCell(...)), so we need copy this method in our class. This code
doubling is not good in my opinion.
Would you mind to add a customization for this case to chose mouseDown
and MouseUp event? Perhaps, it would be useful for multi cell selection.
What do you think about it?
Thank you in advance.
Regards
Andrey
> Andrey schrieb:
>> Dear colleagues
>>
>> I�ve met some issue with the strategy with mouse event. It works by
>> mouse down event only. Perhaps, it covers most requests, but I need
>> select several cells by mouse dragging (e.g. because of single click
>> editor activation strategy). So I�ve customized the strategy by
>> overriding hookEditingSupport() method for handling mouse up/down and
>
> Is this really needed why are you not simply overloading
>
> ColumnViewerEditorActivationStrategy#isEditorActivationEvent () like
> shown in
> http://wiki.eclipse.org/JFaceSnippets#Snippet026TreeViewerTa bEditing?
>
>> calculating some flag . The flag allows make decision about starting
>> of editor. But it looks like a hack. So I�d like to ask you about some
>> improvement of Grid. Perhaps, it�d be useful for other user of the
>> library.
>>
>> 1. Could you modify the cell activation strategy for any event (not only
>
> Which event beside Mouse and Keyboard do you think is need for
> Activation? You can always force activation by
> ColumnViewer#editElement(Object,int).
>
>> for mouse down event). 2. What do you think about some useful method
>> like ColumnViewer#getCell with default access? Have you considered
>
> Why do you need this method, log a bug against Platform/UI and prefix
> your summary with [Viewers] and make sure you give us use-case without
> one opening API is hard to push through :-)
>
>> asking developer of jface to change its modifier? 3. What do you think
>> about adding some �deactivation strategy� for behavior customization?
>
> What do you want to customize? You can already register as a listener
> and get notified when the editor is deactivated I'm not sure currently
> whether you can veto it.
>
> Tom
>
|
|
| | | |
Goto Forum:
Current Time: Thu Apr 18 15:43:39 GMT 2024
Powered by FUDForum. Page generated in 0.04396 seconds |
] 
Search
Help
Register
Login
Home
