Eclipse Community Forums: Albireo » Context Help in SwingControl

Help

Home

Home » Archived » Albireo » Context Help in SwingControl

Show: Today's Messages :: Show Polls :: Message Navigator

Context Help in SwingControl [message #6814]

Tue, 02 September 2008 09:59

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Hi,

I'm using eclipse albireo to integrate a Swing diagram editor into Eclipse.
Albireo solved many issues already, so first of all, thank you for your
valuable efforts.
However, now I want to provide context sensitive help for diagram
elements and it is causing me some problems.
I'll try to explain the scenario:
The Eclipse Editor uses a SwingControl that creates a JScrollPane that
finally contains the Swing diagram editor.
The Editor returns an adapter for IContextProvider that reacts to
SELECTION. It then computes a context for the given selection. This all
works just fine, until I activate another WorkbenchPart while the Help
View is still open. Once the other part is activated, the Help View
displays the help content for the other part.
When I click back into the Swing Editor, the HelpView correctly invokes
the handlePartActivation method.
In handlePartActivation, the following check is done:

Control c = display.getFocusControl();
if (c != null && c.isVisible() && !c.isDisposed())

In my case, display.getFocusControl returns null.
I am assuming, that is because the SwingControl passed the focus to the
embedded swing editor and therefore no SWT control is focused.
However, without a focused control, the help view refuses to update the
help content and the only way to display the correct context is by
closing it and pressing F1 again.
Am I doing anything wrong? Any hints on how to work around that?
Or is this more an issue with the code of the help view that I should
post in another newsgroup?

Thanks in advance and best regards,
Johannes

Report message to a moderator

Re: Context Help in SwingControl [message #6822 is a reply to message #6814]

Tue, 02 September 2008 20:47

Gordon Hirsch

Messages: 100
Registered: July 2009

Senior Member

Johannes Utzig wrote:
....
> When I click back into the Swing Editor, the HelpView correctly invokes
> the handlePartActivation method.
> In handlePartActivation, the following check is done:
>
> Control c = display.getFocusControl();
> if (c != null && c.isVisible() && !c.isDisposed())
>
> In my case, display.getFocusControl returns null.
> I am assuming, that is because the SwingControl passed the focus to the
> embedded swing editor and therefore no SWT control is focused.

In the case of an embedded Swing component, Display.getFocusControl()
normally returns the parent SWT composite. (To be fair, I've only
verified this on Windows.) If that happened correctly for you, then
there would be no problem in updating the help view.

However, we've learned the hard way that getFocusControl() will not
return reliable results immediately after an embedded Swing Control
gains focus due to timing issues. My guess is that this is the problem
you are seeing. Under these conditions, getFocusControl() will sometimes
return the previously focused component and sometimes null, in my
experience.

See this bugzilla:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=221241

> However, without a focused control, the help view refuses to update the
> help content and the only way to display the correct context is by
> closing it and pressing F1 again.
> Am I doing anything wrong?

Nope :-)

> Any hints on how to work around that?
> Or is this more an issue with the code of the help view that I should
> post in another newsgroup?

I don't think there is anything the help view itself can or should do
differently. Can you trigger a programmatic help view update somehow?
After some amount of time, Display.getFocusControl() should return the
right value. If the help "activation" code can be rerun at that point,
it should update correctly. Or if there's some other way to nudge the
view...

If you find a solution, please post back here. Also, feel free to open
an Albireo bug entry. Maybe there's something that can be done at the
Albireo level, although I can't think of anything at the moment.

>
> Thanks in advance and best regards,
> Johannes

Report message to a moderator

Re: Context Help in SwingControl [message #8596 is a reply to message #6822]

Thu, 04 September 2008 21:23

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Thank you for your quick reply.

I tried I few things and my current 'solution' is the following:
The outer JScrollPane is set to focusable=true and registers a focus
listener to itself that calls requestFocus on the inner diagram editor.
I did that, because I noticed in the code that SwingControl behaves
differently if the direct child is focusable and that seems to solve the
main issue at least (i.e. it didn't work at all after another workbench
part was activated).
Now it's no longer a deterministic failure, but has more the notion of a
timing condition (the one you mentioned).
If I have to make a guess, I'd say the context change works in 80% of
the tries (on Windows that is, we'll see how KDE and GTK behave).
I tried several other things, like Thread.yield(), invokeLater and so on
in various spots, but the constellation above seems to work best so far.

>
>> Any hints on how to work around that?
>> Or is this more an issue with the code of the help view that I should
>> post in another newsgroup?
>
> I don't think there is anything the help view itself can or should do
> differently. Can you trigger a programmatic help view update somehow?
> After some amount of time, Display.getFocusControl() should return the
> right value. If the help "activation" code can be rerun at that point,
> it should update correctly. Or if there's some other way to nudge the
> view...
>

Well, for my use-case it certainly would be better if the Help View
would not rely on controls too much. To me it looks as if they only need
the SWT control to generate some default content in case you have non
defined. If the provider comes up with all the necessary content, it's
probably not required to have an associated control. However, embedded
Swing is somewhat exotic, so they are probably not very interested in
changing their code for just that. I also have to point out that I
didn't dig deep enough into the code yet to make a clear statement about
that...
Manually invoking an update seems like a dead end. It's all private
methods in a class that's in an internal package. Actually, I'd even be
willing to force my way through with reflection, but I couldn't find a
clean way to determine if the help view actually is in *context
sensitive state* and wants to be updated on a selection changed event.

> If you find a solution, please post back here. Also, feel free to open
> an Albireo bug entry. Maybe there's something that can be done at the
> Albireo level, although I can't think of anything at the moment.
>

I'll post here again if I find out further details, or maybe even a
solution. Until then, I guess I have to live with the round about 80%
solution. If one is embedding Swing in SWT, one has to make compromises,
I already learned that the hard way. ;)

Best regards,
Johannes

Report message to a moderator

Re: Context Help in SwingControl [message #8611 is a reply to message #8596]

Mon, 22 September 2008 19:16

Gordon Hirsch

Messages: 100
Registered: July 2009

Senior Member

Johannes Utzig wrote:
>
> I tried I few things and my current 'solution' is the following:
> The outer JScrollPane is set to focusable=true and registers a focus
> listener to itself that calls requestFocus on the inner diagram editor.
> I did that, because I noticed in the code that SwingControl behaves
> differently if the direct child is focusable and that seems to solve the
> main issue at least (i.e. it didn't work at all after another workbench
> part was activated).

I've been thinking about this general case a bit. We shouldn't be
checking just the direct child for focusability. I've committed a change
to CVS that loosens the focusability check to look for *any* child with
focusable == true.

I can't tell for sure, but I hope this change would remove the need for
your focus listener. It depends on how your Swing component's focus
policy is defined.

Report message to a moderator

Re: Context Help in SwingControl [message #8622 is a reply to message #8611]

Wed, 08 October 2008 14:46

Johannes Utzig

Messages: 329
Registered: July 2009

Senior Member

Gordon Hirsch schrieb:
> I've been thinking about this general case a bit. We shouldn't be
> checking just the direct child for focusability. I've committed a change
> to CVS that loosens the focusability check to look for *any* child with
> focusable == true.
>
> I can't tell for sure, but I hope this change would remove the need for
> your focus listener. It depends on how your Swing component's focus
> policy is defined.
>

Hi Gordon,

sorry for my belated reply.
The direct child of the editor extends JScrollPane and its viewport is
the (focusable) diagram editor. So that would indeed eliminate my need
for the focus listener hack.
Before implementing this hack I thought about removing the outer
scrollpane and use a scrollable SWT composite but I came to the
conclusion that this would probably mess too much with the Swing editors
behaviour (JComponent#setAutoscrolls for example)
I think your change is a good idea, thank you for that.

Best regards,
Johannes

Report message to a moderator