Home » Archived » Albireo » Context Help in SwingControl
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
|
|
|
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
|
|
|
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
|
|
| | |
Re: Context Help in SwingControl [message #574240 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
|
|
|
Re: Context Help in SwingControl [message #574266 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
|
|
| | |
Goto Forum:
Current Time: Sat Oct 19 12:40:38 GMT 2024
Powered by FUDForum. Page generated in 0.05318 seconds
|