| Focus display and traversing [message #178573] |
Wed, 20 April 2005 21: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 #178617 is a reply to message #178590] |
Wed, 20 April 2005 22:10  |
| Eclipse User |
|
|
|
Originally posted by: bo.n0spam.majewski.com
Pratik Shah wrote:
> In configureGraphicalViewer() method of your Editor, set a
> GraphicalViewerKeyHandler as the handler for the graphical viewer.
> The specific method in the class GraphicalViewerKeyHandler is
> navigateNextSibling().
Excellent, thanks! Now one more question. How do cause GEF to call the
showFocus method?
I return a NonResizableEditPolicy from the createChildEditPolicy method
of the XYLayoutEditPolicy instance. Yet the showFocus never seems to be
called. I traced it back to the fact that setFocus is always called with
false. I explicitly set in the figure focus flags
this.setRequestFocusEnabled(true);
this.setFocusTraversable(true);
But that does not seem to have any result.
|
|
|
|
| Re: Focus display and traversing [message #178640 is a reply to message #178633] |
Wed, 20 April 2005 23: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 21:07 |
 Pratik Shah
Messages: 1077
Registered: July 2009 |
Senior Member |
|
|
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 #178793 is a reply to message #178777] |
Thu, 21 April 2005 22:37 |
| Eclipse User |
|
|
|
Originally posted by: bo.n0spam.majewski.com
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!
|
|
|
| Re: Focus display and traversing [message #178869 is a reply to message #178793] |
Fri, 22 April 2005 20: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.04391 seconds
] 
Search
Help
Register
Login
Home
