[news.eclipse.technology.albireo] Re: Context Help in SwingControl

[Johannes Utzig <mail@xxxxxxxxx>]

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