| Focus display and traversing [message #178573] |
Wed, 20 April 2005 17:02  |
Eclipse User |
|
|
|
Originally posted by: bo.n0spam.majewski.com
I noticed that the logical example displays focus and allows focus
traversing, using arrow keys. Could some kind soul point me to the code
that does exactly this. I need to enable the same feature in our
application.
|
|
|
|
|
|
| Re: Focus display and traversing [message #178640 is a reply to message #178633] |
Wed, 20 April 2005 19:20  |
| Eclipse User |
|
|
|
Originally posted by: bo.n0spam.majewski.com
Pratik Shah wrote:
> editpart. See SelectionEditPolicy#addSelectionListener(). So, the flow is:
> key handler determines the next editpart, and sets it as the focus part on
> the viewer; the viewer updates the editpart's selection state, which
> notifies the editpolicy, which then shows the focus. It should be simple to
> debug and see which step is failing.
I see the following:
1. GraphicalViewerKeyHandler.navigateTo calls getViewer().select(part).
The part is correctly set to the part managing selected object
2. ScrollingGraphicalViewer.select calls appendSelection(editpart) with
the selected part. The selected part is still valid.
3. ScrollingGraphicalViewer.appendSelection(EditPart editpart) compares
the editpart with the focusPart. The latter is null. As a result, it
sets the focus to null (setFocus(null)).
Later, the part.hasFocus() returns false consistently, as it is never
given focus.
The focusPart, defined in the AbstractEditPartViewer class remains
stubbornly null throughout the life of the program. It seems that the
only way to set it is via setFocus method. However, this one is called
with null, as the non-null value in appendSelection causes a call to
setFocus with null as the parameter.
I guess I don't understand why the appendSelection method uses the
following code:
if (editpart != focusPart)
setFocus(null);
I re-implemented the createGraphicalViewer method as follows, and it
gives me the selection rectangle:
protected void createGraphicalViewer(Composite parent) {
GraphicalViewer viewer = new ScrollingGraphicalViewer() {
public void appendSelection(EditPart editpart) {
super.appendSelection(editpart);
if (editpart != focusPart) {
setFocus(editpart);
}
}
};
viewer.createControl(parent);
setGraphicalViewer(viewer);
configureGraphicalViewer();
hookGraphicalViewer();
initializeGraphicalViewer();
}
I am using GEF 3.0.1 ... maybe this has been changed in subsequent
releases ...
|
|
|
| Re: Focus display and traversing [message #178777 is a reply to message #178640] |
Thu, 21 April 2005 17:07 |
| Eclipse User |
|
|
|
Okay, I am a little confused...are you talking about focus or selection?
GEF doesn't show focus when a part is selected (since it's already showing
selection handles feedback, and focus feedback is just annoying). However,
if you hit Ctrl + arrow key in the logic example, it will show focus (since
the part now has focus, but no selection). Only when you do this will
showFocus() be called.
"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d46o6j$mmu$1@news.eclipse.org...
> Pratik Shah wrote:
> > editpart. See SelectionEditPolicy#addSelectionListener(). So, the flow
is:
> > key handler determines the next editpart, and sets it as the focus part
on
> > the viewer; the viewer updates the editpart's selection state, which
> > notifies the editpolicy, which then shows the focus. It should be
simple to
> > debug and see which step is failing.
>
> I see the following:
>
> 1. GraphicalViewerKeyHandler.navigateTo calls getViewer().select(part).
> The part is correctly set to the part managing selected object
>
> 2. ScrollingGraphicalViewer.select calls appendSelection(editpart) with
> the selected part. The selected part is still valid.
>
> 3. ScrollingGraphicalViewer.appendSelection(EditPart editpart) compares
> the editpart with the focusPart. The latter is null. As a result, it
> sets the focus to null (setFocus(null)).
>
> Later, the part.hasFocus() returns false consistently, as it is never
> given focus.
>
> The focusPart, defined in the AbstractEditPartViewer class remains
> stubbornly null throughout the life of the program. It seems that the
> only way to set it is via setFocus method. However, this one is called
> with null, as the non-null value in appendSelection causes a call to
> setFocus with null as the parameter.
>
> I guess I don't understand why the appendSelection method uses the
> following code:
>
> if (editpart != focusPart)
> setFocus(null);
>
> I re-implemented the createGraphicalViewer method as follows, and it
> gives me the selection rectangle:
>
> protected void createGraphicalViewer(Composite parent) {
> GraphicalViewer viewer = new ScrollingGraphicalViewer() {
> public void appendSelection(EditPart editpart) {
> super.appendSelection(editpart);
> if (editpart != focusPart) {
> setFocus(editpart);
> }
> }
> };
> viewer.createControl(parent);
> setGraphicalViewer(viewer);
> configureGraphicalViewer();
> hookGraphicalViewer();
> initializeGraphicalViewer();
> }
>
> I am using GEF 3.0.1 ... maybe this has been changed in subsequent
> releases ...
|
|
|
|
| Re: Focus display and traversing [message #178869 is a reply to message #178793] |
Fri, 22 April 2005 16:06 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The alignment/match actions are indicated by the handles which are black.
All the other handles should be white.
Focus also appears if you are on a selected editpart, and press CTRL+SPACE,
to deselect it.
"Bo Majewski" <bo@n0spam.majewski.com> wrote in message
news:d49a2f$gqs$1@news.eclipse.org...
> Pratik Shah wrote:
>> Okay, I am a little confused...are you talking about focus or selection?
>> GEF doesn't show focus when a part is selected (since it's already
>> showing
>> selection handles feedback, and focus feedback is just annoying).
>> However,
>> if you hit Ctrl + arrow key in the logic example, it will show focus
>> (since
>> the part now has focus, but no selection). Only when you do this will
>> showFocus() be called.
>
> Ah, so ... :-) OK, it works with Ctlr+Arrow without overriding the
> appendSelection method.
>
> The primary reason for having focus AND selection are the Match Width and
> Match Height actions. I thought that I can show with focus what is the
> primary selection. This then indicates to the user which object is going
> to used as the template for height or width operations. Now I noticed that
> primary selection is indicated with filled handles and non-primary with
> empty ones.
>
> Any-who, thanks for your help!
|
|
|
Powered by
FUDForum. Page generated in 0.05474 seconds
Home